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Preface 



Database systems are central to the operation of most organisations and 
systems today. Over the years promising new developments in software 
engineering e.g., object-oriented (OO) techniques, have had an impact on 
the way we develop, maintain and use database systems. This impact has 
ranged from development of new data management mechanisms (in order 
to service new programming paradigms e.g., OO) to maintenance tech- 
niques through to APIs, libraries and frameworks for interacting with the 
database from application programs. 

A similar promising development is the emerging set oi Aspect-Oriented 
Software Development (AOSD) techniques. These techniques offer system- 
atic means to manage crosscutting concerns such as distribution, security 
and persistence that cannot be easily modularised using conventional tech- 
niques such as object-orientation. Such crosscutting concerns also exist in 
the context of database systems or applications served by them. It is, there- 
fore, natural to explore the relationship between database systems and 
aspect-oriented techniques in order to determine how database systems 
and their applications can benefit from the advanced separation of con- 
cerns afforded by aspect-orientation. At the same time, it is important to 
explore how database systems can support aspect-oriented development in 
the same fashion as databases have previously evolved to support object- 
oriented development. 

The term Aspect- Oriented Database Systems (AODBs), therefore, implies 
the use of aspect-oriented techniques and database systems in conjunction 
with each other. Specifically, in the context of the discussion in this book, it 
refers to: 

• database systems employing aspect-orientation within their implemen- 
tation and operation in order to modularise broadly scoped properties, 
such as evolution and versioning, with a view to improving customis- 
ability, extensibility, evolvability and maintainability; 
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• database systems supporting aspect-oriented development techniques 
by providing means for storage, retrieval and manipulation of aspects; 

• use of aspect-oriented techniques to separate database access and inter- 
action from application code. 

The following sections provide an overview of the book, indicate its tar- 
get audience, outline some relevant resources and acknowledge the various 
people and organisations that have influenced or contributed to my work 
over the years. 



P.1 Outline of the Book 

Chapter 1 provides a basic introduction to database systems focussing on the 
concepts most relevant to the discussion in the following chapters. It also 
elaborates on the notion of Aspect- Oriented Database Systems and intro- 
duces several systems, which form the basis of the discussion in the book. 

Chapter 2 provides an introduction to aspect-oriented programming 
(AOP) for readers not familiar with the concepts. A number of AOP tech- 
niques are discussed and approaches supporting separation of crosscutting 
concerns at earlier software development stages are also summarised. 
Besides offering an introduction to AOP, the chapter also provides readers 
the opportunity to contrast the programming models offered by various 
AOP techniques. 

Chapter 3 discusses the problem of crosscutting concerns in database 
systems and how their lack of modularisation inhibits customisability, 
extensibility, evolvability and maintainability. Several concrete examples of 
concerns cutting across elements in the database management system and 
the database are discussed. The chapter motivates the need to aspectise 
crosscutting concerns in database systems. 

Chapter 4 provides a general model for AOP in database systems before 
moving on to discussing how the concrete examples of crosscutting con- 
cerns, discussed in chapter 3, can be effectively modularised using aspects. 
The discussion draws upon three concrete database systems, SADES, 
GOODS and AspOEv, which employ AOP in their implementation and 
operation to improve modularity and localise the impact of changes. This, 
in turn, provides improved support for customisability, extensibility, 
evolvability and maintainability. A quantitative evaluation of the localisa- 
tion of change impact upon evolution in SADES is also provided. 
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Chapter 5 highlights various aspects that might need to outlive program 
execution and hence require persistent storage. Models for persistent aspect 
stores based on object-oriented and relational database systems are dis- 
cussed. Concrete implementations of the models based on the Jasmine 
object-oriented database system and SQL-92 compliant relational data- 
bases are also detailed. The chapter also discusses models for composing 
aspects in a persistent environment and the potential of mechanisms such 
as weave-on-demand, weaving histories and selective weaving to improve 
the composition efficiency in this context. 

Chapter 6 provides the reader with a large-scale example of the use of 
AOP in relation to database systems. It uses a classical database application, 
a bibliography system, as a basis to discuss how Aspect} (an aspect language 
for Java) can be used to modularise code relating to accessing and interact- 
ing with SQL-92 compliant relational databases. The interesting features of 
the chapter include: a real-world example of the use of AOP, provision 
of rationale behind the design of the various aspects and classes employed, 
and a discussion of how the resulting design may be employed when 
modularising persistence code relating to object-oriented and object-rela- 
tional database systems. 

Chapter 7 concludes the book by summarising the concepts discussed 
and providing an outlook on the potential impact of AOP and database sys- 
tems on each other. 



P.2 Who should Read this Book? 

This book is aimed at professionals who are experienced in database systems, 
AOP or both. For database professionals, it offers insight into how AOP can 
serve as a means to build more modular database systems that are customis- 
able, extensible and maintainable in the face of changing requirements. For 
AOP professionals, it provides concrete examples of the use of AOP in an 
application domain fundamental to most businesses. It also describes how 
database systems can support AOP by providing support for aspect mining 
and reuse. Professionals experienced in both AOP and database systems can 
gain an understanding of how the two technologies can benefit each other. 
The book may also be useful to students studying advanced courses on data- 
base systems, software engineering or software modularity. 
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P.3 Relevant Resources 

Chapter 1 provides a brief introduction to database systems and the con- 
cepts most relevant to the discussion in Chaps. 3-6. Readers less familiar 
with database systems in general, and object-oriented databases in particu- 
lar, may find the following books useful: 

• R. Elmasri and S. B. Navathe, Fundamentals of Database Systems (3rd 
ed.y. Addison- Wesley, 2000. 

• M. Stonebraker, P. Brown, and D. Moore, Object-Relational DBMSs: 
Tracking the Next Great Wave (2nd ed.): Morgan Kaufmann, 1999. 

• A. B. Chaudhri and R. Zicari (eds.). Succeeding with Object Databases: 
John Wiley, 2001. 

Chapter 2 provides an introduction to AOP for readers who are not 
familiar with the concepts. Additional resources for AOP are: 

• Aspect-Oriented Software Development Web Site: http://aosd.net. 

• T. Elrad, R. Filman, and A. Bader (eds.), “Theme Section on Aspect- 
Oriented Programming”, Communications of ACM, Vol. 44, No. 10, 
2001. 

• A. Rashid (ed.), “Aspect-Oriented and Component-based Software Engi- 
neering”, lEE Proceedings - Software (Special Issue), Vol. 148, No. 3, 2001. 

• G. Kiczales (ed.), “Proceedings of 1st International Conference on 
Aspect-Oriented Software Development”, ACM, 2002. 

• M. Aksit (ed.), “Proceedings of 2nd International Conference on Aspect- 
Oriented Software Development”, ACM, 2003. 

• A. Rashid and L. Blair (eds.), “Aspect-Oriented Programming and Sepa- 
ration of Crosscutting Concerns”, The Computer Journal (Special Sec- 
tion), Vol. 46, No. 5, 2003. 

• R. Laddad, “Aspect} in Action — Practical Aspect-Oriented Program- 
ming”, Manning, 2003. 
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Introduction 



Database systems are central to the day-to-day activities of most businesses 
today. They are employed for a variety of purposes ranging from basic 
record management to supporting cooperative work, software asset man- 
agement, online analytical processing (OLAP) (Thomsen 2002) and back- 
end data management for Web sites. They are also used to support new data 
management needs, for instance, those pertaining to management of XML 
data (Chaudhri, Rashid, et al. 2003) or data in mobile and ubiquitous 
devices (Ortiz Jr. 2000). In fact, databases have started to become seamless 
to the end users. People using ATMs, airline reservation systems, dynamic 
Web sites or devices with embedded databases seldom realise that they are 
using a database. 

Despite their widespread use, database systems are developed from the 
viewpoint of having a single data management solution that fits all applica- 
tions. Consequently, they tend to be inflexible resulting in applications to 
be fitted around the features offered by the database system and not vice 
versa. This lack of customisability and adaptability often arises due to the 
fact that features, for which customisation might be desirable, tend to be 
broadly scoped and have a system wide effect. Furthermore, persistence, 
i.e., the storage and retrieval of application data from secondary storage 
media, is a concern that is spread across other application elements. 

Recently, a new set of software development techniques - termed Aspect- 
Oriented Software Development (AOSD) - have become available that aim 
to support modularisation of systemic properties (also referred to as cross- 
cutting concerns as they cut across other concerns in a system) and their sub- 
sequent composition with other parts of the system. This book focuses on 
the use of Aspect-Oriented Programming (AOP) techniques to modularise 
otherwise broadly scoped features in database systems to improve their cus- 
tomisability and flexibility. The aim is to discuss how the use of AOP can 
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transform the way we develop, use, maintain and interact with database 
systems. The book also discusses how database systems can support AOP by 
providing means for storage and retrieval of aspects - modules used to 
encapsulate broadly scoped properties in AOP - to provide improved sup- 
port for software asset management. 

In the following. Sect. 1.1 provides a basic introduction to database sys- 
tems and the key concepts relevant to the examples used throughout the 
book. Section 1.2 introduces the term Aspect- Oriented Database Systems 
(AODBs) as a framework that encompasses various facets of the relation- 
ship between aspect-orientation and database systems. It also introduces 
existing AODBs, several of which are used as a basis of the discussion in the 
book. Section 1.3 concludes the chapter. 



1 .1 Database Systems 

The term “database system” encompasses two elements: 

• the database: the persistent store used to hold the data and data defini- 
tions (the schema) on secondary storage media; 

• the database management system (DBMS) : the software used to manage, 
i.e., store, retrieve, manipulate and evolve, the data in the database and 
its schema. 

The data is stored in the database with reference to the data model sup- 
ported by the database management system. The most commonly 
employed data model is the relational model (Codd 1970). In relational 
databases (RDBs), data is normalised to a set of relational tables employing 
a restricted set of basic data types. Each row in the table corresponds to an 
entity or a relationship to be stored in the database. The model has a strong 
mathematical foundation in set theory and relational algebra and is the 
basis of most commercial and freely available systems, e.g., Oracle, DB2, 
SQL Server, Ingres and MySQL. 

Object-oriented databases (OODBs) (Cattell, Barry, et al. 2000) were con- 
ceived to avoid the impedance mismatch arising from the need to dismantle 
data in object-oriented (OO) applications for storage in relational tables. 
They aim to provide seamless integration between objects in OO applica- 
tions and their database representation. A number of object-oriented data- 
base systems are available on the market, e.g., POET, Objectivity, Object 
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Store and Jasmine. However, relational database systems remain the dom- 
inant force due to lack of compliance with standards on part of object data- 
base systems and a significant investment in relational databases on part of 
vendors and users. 

Object-relational database systems (ORDBs) (Stonebraker, Brown, et al. 
1999) attempt to address some weaknesses of the relational model, e.g., the 
inability to cope with complex, user-defined types, without transition to a 
pure OO solution. They extend the basic relational model with OO con- 
cepts, such as abstract data types and inheritance. Major relational database 
vendors, e.g., Oracle and IBM, now offer object-relational products. This 
might be an intermediate step leading to a transition to pure object-ori- 
ented data management solutions. 

The examples discussing the use of AOP in database systems in this book 
have been mainly derived from three topics: 

• schema evolution in object-oriented databases; 

• versioning and workgroup support in database systems; 

• transaction processing. 

The following sections introduce these concepts. 



1.1.1 Schema Evolution in Object-Oriented Databases 

The schema of an object database is mainly subject to two types of modifi- 
cations over its lifetime: 

• Class hierarchy modification; 

• Class structure modification. 

1 .1 .1 .1 Class Hierarchy Modification 

Evolution of the conceptual structure of an object database might involve 
the introduction of new classes. Consider, for example, a simple object 
database schema with two classes A and B where class B is a subclass of 
class A. Fig. 1.1a shows an evolution scenario involving the introduction 
of a new class C as a leaf node in the class hierarchy. As summarised in Table 
1.1, such a change does not have any impact on existing classes, their 
instances or any existing or future references to these in application pro- 
grams or methods in other classes. However, if the new class C is introduced 
as a non-leaf node in the hierarchy (cf. Fig. 1.1b), the subclasses and their 
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instances need to be modified in order to ensure consistency and validity of 
future references. Deletion of classes and modification of their inheritance 
links pose similar problems. For example, assume that the scenarios in Fig. 
1.1 represent the pre-evolution states. The evolution operation involves 
deletion of cl ass C. In case of Fig. 1.1a, instances of cl ass C will either 
have to be removed or migrated to another class. References to c 1 a s s C and 
its instances in existing application programs and methods of other classes 
will become invalid. In the case of Fig. 1.1b, deletion of cl ass C will cause 
these effects to spill over to its subclass (class B) and its instances. These 
impacts and those resulting from modification of inheritance links have 
been summarised in Table 1.1. It should be noted that mechanisms based 
on structural type equivalence (Albano, Dearie, et al. 1989) only provide 
partial solutions to these problems. In (Conner, Cutts, et al. 1994), for 
example, addition of a new class is possible but deletion of a class is only 
possible after all the objects bound to the class have been collected by the 
garbage collector. 

There are also other factors that must be taken into account: 

• Any class hierarchy modification must not introduce cycles in the hier- 
archy graph (Banerjee, Chou, et al. 1987). 

• Conflicts between locally defined and inherited properties and methods 
must be resolved. 

• If the system supports multiple inheritance duplication resolution due to 
multiple inheritance paths must be addressed. 




(a) (b) 



Fig. 1.1. Example schema evolution scenarios 
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Tool support can be used to ensure the consistency of the conceptual 
structure of the database during evolution. (Delcourt and Zicari 1991), for 
example, introduce a tool called ICC (Integrity Consistency Checker) for 
the purpose. (Breche, Ferrandina, et al. 1995) propose the use of view 
mechanisms to check the validity and appropriateness of a change before it 
is actually carried out. 



Table 1.1. Summary of schema changes and their impacts 



Affected 

Entities 

Type of 
Evolution 


Instances 
(if any) 


Subclasses 
(if any) 


Subclass 
instances 
(if any) 


Existing/Future 

References 


Addition of a 
leaf class 


N/A 


N/A 


N/A 


N/A 


Addition of a 
non-leaf class 


N/A 


Affected 


Affected 


N/A 


Deletion of a 
leaf class 


Affected 


N/A 


N/A 


Affected 


Deletion of a 
non-leaf class 


Affected 


Affected 


Affected 


Affected 


Modification of 
inheritance 
links of a leaf 
class 


Affected 


N/A 


N/A 


Affected 


Modification of 
inheritance 
links of a non- 
leaf class 


Affected 


Affected 


Affected 


Affected 


Modification of 
structure of a 
leaf class 


Affected 


N/A 


N/A 


Affected 


Modification of 
structure of a 
non-leaf class 


Affected 


Affected 


Affected 


Affected 



1 .1 .1 .2 Class Structure Modification 

Class structure modifications can have effects similar to class hierarchy 
modifications. Structure modifications include addition, deletion and 
modification (e.g., changing the domain of an attribute or the signature of 
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a method) of properties and methods. For example, let the scenarios in Fig. 

1.1 indicate schema states prior to the addition of an attribute to class C. 
In the scenario in Fig. 1.1a, instances of cl ass C will be inconsistent with 
the class definition following addition of the attribute. Any future refer- 
ences to access the newly added attribute will result in errors as instances 
existing prior to evolution do not contain this attribute value. In the case of 
Fig. 1.1b this impact will spill over to class B and its instances. These 
impacts have been summarised in Table 1.1. 

1 .1 .1 .3 Backward and Forward Compatibility 

The discussion in Sects. 1.1. 1.1 and 1.1. 1.2 identifies two types of anoma- 
lous behaviour as a consequence of evolution: 

• Objects created under the older schema definition might not be accessi- 
ble under the new definition and vice versa. 

• Application programs accessing the database prior to evolution might 
contain invalid references and method calls. Note that inaccessibility in 
this context applies to both methods and attributes and hence the object 
as a whole. 

The former has been termed as a structural consistency issue and the latter 
a behavioural consistency issue (Zicari 1991). 

1 .1 .1 .3.1 Structural Consistency 

An example of a structural consistency problem is depicted in Fig. 1.2. 
Person_01 d is the class definition prior to evolution. The evolution opera- 
tion involves introduction of a new attribute age resulting in the class defi- 
nition P e r s 0 n_N e w. As shown in Fig. 1 .2, when an application using the new 
class definition attempts to access an object instantiated using the old class 
definition an error will occur as the object does not have an attribute age. 

As summarised in Table 1.2, changes that are additive in nature, e.g., 
addition of a property (attribute or relationship) or specialisation of the 
domain of a property are backward compatible. For example, from Fig. 1.2, 
an application using the class definition P e r s o n_0 1 d will have no problems 
accessing the objects instantiated using the definition Person_New. Changes 
that are subtractive in nature, e.g., dropping a property or generalising the 
domain of a property are forward compatible. Arbitrary changes to the 
domain of a property or renaming a property are changes that are neither 
forward nor backward compatible. It is clear that, in order to ensure full for- 
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ward and backward structural compatibility, special measures need to be in 
place to either convert objects between class definitions or make objects 
exhibit a compatible interface when accessed using a class definition differ- 
ent from the one used to instantiate them. This is called instance adaptation. 




Another structural consistency concern is the choice between an imme- 
diate update and a deferred update strategy. In an immediate update all 
objects are transformed, both logically and physically, to conform to the 
new class definitions as soon as the modification is performed. It has the 
advantage of having the entire database in a consistent state with respect to 
the new schema. It has the disadvantage of being expensive and time-con- 
suming as all running programs have to be suspended until the database 
update is finished. In the deferred update strategy objects logically conform 
to the new schema after the change. They are physically transformed only 
when they are effectively used. The advantage is that the entire database 
does not need to be locked. However, change histories need to be main- 
tained and there is an overhead in terms of run-time checks on objects. 
(Ferrandina, Meyer, et al. 1995) regard a deferred database update as cor- 
rect if the results of the transformation are the same with an immediate 
update. A formal proof of correctness for deferred updates using transfor- 
mation functions can be found in (Ferrandina, Meyer, et al. 1994). 



Table 1.2. Forward and backward structural compatibility of changes 



Type of modification 


Forward Compatible 


Backward Compatible 


Add a property 


No 


Yes 


Drop a property 


Yes 


No 
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Table 1.2. Forward and backward structural compatibility of changes (continued) 



Type of modification 


Forward Compatible 


Backward Compatible 


Generalise property domain 


Yes 


No 


Specialise property domain 


No 


Yes 


Arbitrary changes to property 
domain 


No 


No 


Rename a property 


No 


No 



1 .1 .1 .3.2 Behavioural Consistency 

Changes to the conceptual structure of an object-oriented database can 
affect the behavioural consistency in two ways: 

• If methods of the class being modified contain references to the modified 
properties or methods, they might behave erroneously. 

• If methods in other classes and applications contain references to the 
modified properties or methods, they might behave erroneously. 

An example of a behavioural consistency problem is shown in Fig. 1.3. 
The application is bound to the class definition prior to evolution: 
Person_01d. The application invokes the method getPersonName() to 
obtain the name of a person. The evolution operation renames the method 
to getNameC ) resulting in the class definition Person_New. The applica- 
tion, however, still has a call togetPersonName() embedded within itself 
Any attempts by the application to invoke the method will result in a runt- 
ime error. 

Table 1.3 summarises the various changes to a class definition and their 
behavioural consistency. Some changes have a “1/2” value because they 
leave some of the references unaffected. It should also be noted that 
although the summary in Table 1.3 has been carefully compiled, the diverse 
nature of programming languages and programming practices could lead 
to slightly different results. An analysis of behavioural consistency prob- 
lems in the context of both untyped and strongly typed programming lan- 
guages can be found in (Bergstein and Huersch 1993). The problem is more 
serious in strongly typed languages due to the restrictions imposed by the 
type system. 
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(a) 




I Applicalion 



(b) 



Fig. 1.3. Example of a behavioural consistency problem: (a) Class definition before 
evolution (b) Class definition after evolution 



Table 1.3. Behavioural consistency of changes 



Type of change 


Behaviourally 

Consistent 


Reason 


Add a property or method 


Yes 


No existing references 


Drop a property or 
method 


No 


Existing reference become invalid 


Generalise property 
domain 


1/2 


Any assignments to the property stay 
unaffected. If the property is assigned 
to another variable errors could occur. 


Specialise property 
domain 


1/2 


Any assignments to the property could 
result in errors. Assignments of the 
property value to other variables stay 
unaffected. 


Arbitrary changes to 
domain of a property or a 
method return value 


No 


Existing references become invalid 


Rename a property or 
method 


No 


Existing references become invalid 


Generalise domain of 
method return value 


1/2 


Method code behaves in an orderly 
fashion. Applications using method 
results could have run-time errors. 
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Table 1.3. Behavioural consistency of changes (continued) 



Type of change 


Behaviourally 

Consistent 


Reason 


Specialise domain of 
method return value 


1/2 


Applications using method results stay 
unaffected. Method will have an error 
when attempting to return. 


Generalise domain of a 
method parameter 


1/2 


Method calls in applications stay unaf- 
fected. There will be a signature mis- 
match error and method code might 
behave erroneously. 


Specialise domain of a 
method parameter 


1/2 


Method code will behave correctly. 
Method calls in applications will 
become invalid. There will be a signa- 
ture mismatch error. 


Add a parameter to a 
method 


1/2 


Method code will behave correctly. 
Method calls in applications will 
become invalid. There will be a signa- 
ture mismatch error. 


Drop a parameter of a 
method 


No 


Existing references become invalid 


Rename a parameter of a 
method 


No 


Existing references become invalid 



1 .1 .1 .4 Need for Dynamic Changes 

Several applications (e.g., banking systems) cannot be taken offline to per- 
form evolution operations. Any downtime can incur high costs for the 
organisation. Hence, changes need to be made dynamically while the sys- 
tem is online. The efficiency of the change is crucial as is the requirement to 
minimise transaction conflicts during the change. 



1 .1 .2 Versioning and Workgroup Support 

In computer-aided design and manufacturing (Afsarmanesh, Knapp, et al. 
1985) there is a need to keep track of data modifications in case it is desir- 
able to return to an earlier version of the design. Temporal object-oriented 
data models (Rose and Segev 1991; Su and Chen 1991; Kaefer and Schoen- 
ing 1992; Goralwalla and Ozsu 1993; Bertino, Ferrari, et al. 1998) provide 
many of the elements necessary for organising data across time such as 
keeping track of an object’s creation time and the time when it is modified. 
However, in a CAD/CAM environment a change must be semantically 
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meaningful and correlated with changes to related data in other design rep- 
resentations. Appending change timestamps cannot model the rich seman- 
tics of such a change (Katz 1990). These semantics are captured through 
object versions (Chou and Kim 1986; Katz, Chang, et al. 1986; Klahold, 
Schlageter, et al. 1986; Ecklund, Ecklund, et al. 1987; Ketabchi and Berzins 
1987; Dittrich and Lorie 1988; Katz 1990; Oussalah and Urtado 1997; San- 
toyridis, Carnduff, et al. 1997) derived using explicit version creation oper- 
ations and not simply because of an update. 

(Loomis 1992; Khoshafian 1993; Rao 1994) identify two forms of ver- 
sioning: 

• Linear versioning 

• Branch versioning 

In the case of linear versioning only a single new version can be created 
from each existing version of an object. In branch versioning, multiple 
designers can update the same version of an object. The multiple versions 
originating as a result are then merged together to form a final version. 

(Chou and Kim 1986; Katz, Chang, et al. 1986; Ecklund, Ecklund, et al. 
1987; Ketabchi and Berzins 1987; Katz 1990; Santoyridis, Carnduff, et al. 
1997) complement versioning with the notions of public, group and private 
workspaces in order to support group work. Such long-running activities 
require support for long transactions. Versions are checked out of the shared 
workspaces, worked upon and checked in as new versions. 

(Katz, Chang, et al. 1986; Katz 1990; Santoyridis, Carnduff, et al. 1997) 
also provide additional semantics to versions. A version can be a transient 
version, a working version or a released version. A transient version repre- 
sents an incomplete design and can be deleted or updated at will. When a 
transient version becomes stable and coherent it is upgraded to a working 
version. A working version is frozen and cannot be updated. It can, how- 
ever, be deleted or have transient versions derived from it. When a working 
version is upgraded to the status of released version it can neither be deleted 
nor updated. It can, however, be downgraded to a working version again. 
They also propose assigning one version to be the default version and keep- 
ing track of the most recent version for an object. 

(Katz, Chang, et al. 1986; Klahold, Schlageter, et al. 1986; Katz 1990) 
describe facilities for user-defined views of the design. Issues relating to 
change propagation, constraint propagation and generic references are dis- 
cussed in (Chou and Kim 1986; Katz, Chang, et al. 1986; Dittrich and Lorie 
1988; Katz 1990). 
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(Katz, Chang, et al. 1986; Katz 1990; Santoyridis, Carnduff, et al. 1997) 
also introduce the concept of configurations which are collection of objects 
that must be maintained mutually consistent. They serve as units of ver- 
sioning, taking object versioning to a higher level granularity. Similar work 
has been carried out by (Oussalah and Urtado 1997) who integrate an ele- 
mentary object version graph management technique and a container ver- 
sion management mechanism. The former is termed as the microscopic level 
while the latter macroscopic level. 

Another related issue is the version storage strategy. Two main strategies 
can be employed (Loomis 1995): 

• Versioning-by-copy 

• Versioning-by-difference 

In the versioning-by-copy strategy a new version of an object is imple- 
mented by making a copy of the object, assigning the copy a version num- 
ber and updating references to its predecessors. This technique consumes 
more disk space but provides a form of backup. The versioning-by-difference 
approach, also known as delta-versioning, only records the differences 
between the new version and its predecessors. Delta-versioning is more 
suitable when an application makes relatively minor changes to large 
objects. The technique saves considerable amounts of disk space but 
increases the overhead since the DBMS needs to reconstitute the particular 
version each time it is accessed. 



1.1.3 Transaction Processing 

Transactions are units that encapsulate operations on a database in order to 
take it from one consistent state to another. They employ concurrency con- 
trol and recovery mechanisms to ensure that multiple clients can concur- 
rently access and manipulate the database in a consistent fashion. The clas- 
sical properties of a transaction are the ACID properties: 

• Atomicity implies that a transaction is a unit of operation on the data- 
base. Either all the changes made during a transaction are reflected in the 
database or none at all. 

• Consistency means that the transaction takes the database from one con- 
sistent state to another. Any constraints that hold on the database before 
the transaction still hold after it is completed. 
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• Isolation is the property referring to the visibility of a transaction to other 
transactions executing against the database. Each transaction operates as 
if it is the only one manipulating the database and is not aware of the 
existence of other concurrent transactions. 

• Durability means that the changes made by a transaction are committed 
to the database regardless of any system or media failures. 



1 .2 Aspect-Oriented Database Systems 

Section 1.1 has provided a basic introduction to database systems mainly 
focussing on the concepts most relevant to the discussion in the following 
chapters. This section first provides an overview of the crosscutting nature 
of some of the features introduced in Sect. 1 . 1 in order to provide an under- 
standing of their relevance in the context of this book (their crosscutting 
nature is discussed in more detail in Chap. 3). This leads into a discussion 
of what constitutes an AODB and the features that distinguishes it from a 
conventional database system. Finally, a brief overview of some existing 
AODBs is provided, most of which are used as a basis for the discussion in 
Chaps. 3-6. 



1.2.1 Crosscutting Concerns in Database Systems 

The various concepts introduced in Sect. 1.1 focussed on features of a 
broadly scoped nature. We have, for instance, seen how a schema evolution 
operation pertaining to one class or class element can have an impact on 
other parts of the system. Consequently, any changes to these features or 
elements managing or governing these features can have a non-localised 
impact on the database system. For instance, changes to the evolution 
model that governs the evolution operations can have an impact not only 
on the database but the database management system itself (on elements 
such as the schema manager and the object access manager). Schema 
changes also give rise to the behavioural consistency problem which is 
further compounded by the fact that the persistence-related elements are 
spread across various parts of an application. This has a two-fold impact. 
Firstly, it makes it difficult to bring the application in line with schema 
changes and secondly, persistence-related elements have to be designed for 
specific applications only hence compromising reuse. Even with object-ori- 
ented database systems or standards such as Java Data Objects (JDO) (Roos 
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2002), which aim to promote transparency between transient and persis- 
tent space, transaction calls and queries are intertwined with the primary 
business logic of the application 

If we look at the other concepts discussed in Sect. 1.1, we see a similar 
pattern of crosscutting. For instance, any changes to the versioning or 
workgroup semantics employed by a database system have to be applied to 
all the versioned instances. If the transaction model, a concept fundamental 
to all types of database systems, is modified it can have an impact on a range 
of elements including the locking and recovery mechanisms, the object 
access manager, the caching scheme and so on. 



1.2.2 Fundamentals of Aspect-Oriented Database Systems 

Conventional development techniques and database models are in them- 
selves not sufficient to deal with broadly scoped concerns discussed earlier. 
This significantly compromises the customisability, extensibility, evolvabil- 
ity and maintainability of both database systems and their applications. 
Database systems are built and marketted as single solutions that fit all sce- 
narios and we have come to accept this as a suitable solution to our data 
management problems. However, this lack of customisability, extensibility, 
maintainability and evolvability results in significant human and financial 
resources being invested in adapting existing applications to changing con- 
texts or developing new applications to replace existing ones which no 
longer meet the organisation’s requirements. 

The improved modularisation and separation of concerns offered by 
AOP techniques opens up the possibility to develop database systems and 
applications that are customisable, extensible, evolvable and maintainable 
in the face of changing requirements. This improvement can be afforded at 
both the vendor end to provide pre-fabricated customisations of funda- 
mental components in the form of a product line of database systems or at 
the customer end where developers may customise specific features to meet 
the organisational work practices. 

At the same time, we have to bear in mind that database technology has 
traditionally evolved to service the needs of new software development par- 
adigms. The shift towards object-oriented and object-relational database 
systems and development of transparent data access mechanisms such as 
JDO are indicative of this trend. It is, therefore, also important that data- 
base systems and architectures evolve to support aspect-orientation. This 
could be in the form of providing support for asset repositories where 
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aspects are treated as software assets or acting as data stores for aspects that 
might need to outlive program execution and need to be shared across 
applications. 

The term Aspect- Oriented Database Systems refers to systems that address 
one or more of the three key facets of the relationship between database sys- 
tems and AOP (cf. Fig. 1.4). Note that there are other facets of this relation- 
ship, e.g., aspect-oriented requirements engineering or formal specification 
for database systems. However, these topics themselves are in the early 
stages of development within AOSD. Therefore, these facets are not consid- 
ered in this book. 

As shown in Fig. 1.4, in the current state-of-the-art, an aspect-oriented 
database system has one or more of the following three features: 

• It employs aspect-orientation within its implementation and operation 
in order to modularise broadly scoped properties, such as evolution and 
versioning, with a view to improving customisability, extensibility, 
evolvability and maintainability; 

• It supports aspect-oriented development techniques by providing means 
for storage, retrieval and manipulation of aspects; 

• It uses aspect-oriented techniques to separate database access and inter- 
action from application code. This subsumes generic persistence frame- 
works such as the one discussed in Chap. 6. 

Ideally an AODB would incorporate all three features and hence service 
each of the three key facets of the relationship shown in Fig. 1.4. However, 
currently most systems only service one particular facet. 

Table 1.4 provides an overview of how an aspect-oriented database sys- 
tem may be distinguished from a conventional one. 
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Fig. 1.4. The three facets of the database- AOP relationship encompassed by aspect- 
oriented database systems 



Table 1.4. Comparing a conventional database system and an AODB 



Conventional Database system Aspect-Oriented Database System 



Employs conventional implementation 
techniques (e.g., OO) and architectures 
in its implementation 

Limited customisability, extensibility, 
evolvability and maintainability 

Conventional data models underpin the 
day-to-day operation and data com- 
position 



Does not provide persistence support for 
aspects 

Provides limited or partial support for 
separating persistence concerns from pri- 
mary business logic of an application 



Employs aspect-oriented approaches to 
complement conventional techniques 
and architectures in its implementation 

High degree of customisability, extensi- 
bility, evolvability and maintainability 

The aspect-oriented model complements 
the conventional data model employed 
by the system to facilitate improved sepa- 
ration of concerns and data composition 
in the database 

Provides persistence support for aspects 
to service aspect-oriented applications 

Offers a framework to modularise persis- 
tence concerns in a reusable application 
independent fashion 



1.2 Aspect-Oriented Database Systems 17 



1.2.3 Existing Aspect>Oriented Database Systems 

A number of AODBs or frameworks that service at least one facet of the 
databse system- AOP relationship in Fig. 1 .4 have been developed to date. 
Most of these systems have been developed at the Aspect-Oriented Software 
Engineering Group at Lancaster University UK (http://www.comp. 
lancs.ac.uk/computing/aose). Other groups and projects focussing on 
AODBs and related concepts include work from the Software Productivity 
Group at University of Pernambuco, Brazil (http://jurema.cin.ufpe.br: 
8080/cgi-bin/view/Main/SoftwareProductivityGroup), the Software Engi- 
neering Laboratory at EPFL, Switzerland (http://lgl.epfl.ch), the Aspect- 
Oriented Component Engineering Group at University of Auckland, New 
Zealand (http://www.cs.auckland.ac.nz/-john-g/aspects.html), the JAG 
project (http://jac.aopsys.com), the Generic Object-Oriented Database 
System (GOODS) project (http://www.ispras.ru/-knizhnik/goods/readme. 
htm) and Schmidmeier’s work (http://www.schmidmeier.org/). 

Similar to the initial work on AOP, which has mainly focussed on com- 
plementing OO development, most of the initial AODBs have been based 
on OODBs. However, many of the concepts developed in this context can 
be transferred to ORDBs and RDBs. Already some of the work on AODBs 
is focussing on these systems, e.g., the relational aspect store (Rashid and 
Loughran 2002) discussed in Chap. 5 and the modularisation of persistence 
in relational database applications (Pawlak, Seinturier, et al. 2001; Rashid 
and Chitchyan 2003; Soares, Laureano, et al. 2002) discussed in Chap. 6. 

The various AODBs and frameworks can be categorised on the basis of 
the facets they serviced The following discussion summarises these systems 
on the basis of this categorisation. 

1 .2.3.1 AODBs using AOP in their Implementation and Operation 

The Semi- Autonomous Database Evolution System (SADES) (Rashid and 
Sawyer 1999; Rashid 2000a; Rashid and Sawyer 2000a; Rashid and Sawyer 
2000b; Rashid, Sawyer, et al. 2000; Rashid 200 Id; Rashid 2001c; Rashid 
2001a; Rashid and Sawyer 2001), the Aspect-Oriented Evolution Frame- 
work for Object-Oriented Databases (AspOEv) (Green and Rashid 2002; 
Rashid 2003) and the Generic Object-Oriented Database System (GOODS) 
(Knizhnik 2003) are the three systems employing AOP in their implemen- 
tation and operation. 

1. Readers should note that the various AOP techniques used in the AODBs and frame- 
works discussed here are introduced in Chap. 2. 
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SADES is an object database evolution system built using a combination 
of custom implementations of three AOP techniques: an AspectJ-like 
( Aspect J-Team 2003) aspect language, composition filters (Bergmans and 
Aksit 2001) and adaptive programming (Lieberherr, Orleans, et al. 2001) to 
provide customisable and extensible evolution support. Aspects are 
employed in the implementation of the schema manager, for modularisa- 
tion of change propagation and referential integrity semantics and separa- 
tion of crosscutting concerns in the data residing in the database. The sys- 
tem has built-in support for composition of aspects and often the data 
items delivered are the result of behind-the-scenes aspect composition. 

AspOEv builds upon the work in SADES to support customisability of 
evolution mechanisms in ODMG-compliant (Cattell, Barry, et al. 2000) 
object-oriented databases. The framework, developed in Aspect! (AspectJ- 
Team 2003), is based on a custom database programming language with a 
versioned type system. Similar to SADES, aspects help to modularise evo- 
lution-related elements of the schema manager and often the data items 
delivered are the result of behind-the-scenes aspect composition. 

GOODS is an object-oriented database system which employs reflective 
techniques as a means for AOP to support customisation of its transaction 
model and related concerns such as locking and caching. 

The three AODBs are discussed in more detail in Chap. 4. 

1 .2.3.2 AODBs Supporting Aspect Persistence 

SADES and AspOEv, introduced in Sect. 1.2.3. 1, both support persistent 
storage, retrieval and manipulation of evolution- related aspects. Two other 
key systems, which solely focus on supporting persistent storage, retrieval and 
manipulation of aspects, are PersAJ (Rashid 2000b; Rashid 2002b) and the 
relational aspect store (Rashid and Loughran 2002). PersAJ supports aspect 
persistence based on OODBs while the relational aspect store, as the name 
suggests, does so based on RDBs. Both systems support persistent manage- 
ment of Aspect! aspects though PersAJ can be extended to support other AOP 
techniques. Both these systems are discussed in detail in Chap. 5 alongwith a 
discussion of composing aspects in such a persistent environment. 

1 .2.3.3 AODBs or Frameworks Supporting Separation of Persistence 
Code from Application Logic 

(Rashid and Chitchyan 2003) discuss a framework for modularising persis- 
tence code in relational database applications in a reusable fashion. The 
framework is based on Aspect! and the reflective capabilities of Java. The 
development of the framework and its features are discussed in detail in 
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Chap. 6 and compared with similar approaches, e.g., (Kienzle and Guer- 
raoui 2002; Soares, Laureano, et al. 2002) and the persistence aspect in JAC 
(Pawlak, Seinturier, et al. 2001). 

1 .2.3.4 Facets of the Database-AOP Relationship Addressed by 
Current AODBs 

Table 1.5 summarises the discussion in Sects. 1.2. 3. 1-3 to provide a birds- 
eye view of the facets of the database-AOP relationship addressed by each 
of the AODBs introduced. 



Table 1.5. Facets of the database-AOP relationship addressed by various AODBs 



Facet 


AOP for implemen- 


Persistent aspects Modularisation of 




tation and 


persistence in 


AODB 


operation 


application code 


SADES 


- 


- 


AspOEv 


- 


- 


GOODS 


- 




PersAJ 




- 


Relational aspect 




- 


store 






(Rashid and 
Chitchyan 2003) 






(Soares, Laureano, 
et al. 2003) 






JAC Persistence 
Aspect 






(Kienzle and 




Transactions and 


Guerraoui 2002) 




fault tolerance only 



13 Conclusion 

This chapter has provided an introduction to some database system con- 
cepts and highlighted their relevance in the context of the discussion in this 
book. The term Aspect-Oriented Database Systems and the features covered 
by it have also been introduced along with various AODBs supporting these 
features. The next chapter provides an introduction to AOP concepts and 
some of the main AOP techniques before Chaps. 3-6 discuss AODB con- 
cepts and systems in more detail. 




2. Aspect-Oriented Programming 
(AOP) 



This chapter provides an introduction to AOP. Section 2.1 discusses the 
need to separate concerns, particularly crosscutting concerns, in a software 
system. Section 2.2 describes how crosscutting concerns can be effectively 
modularised with AOP. The programming models offered by some of the 
key AOP approaches are also highlighted. Section 2.3 provides an overview 
of approaches supporting aspect-oriented separation at earlier development 
stages such as requirements engineering, architecture and detailed design. 
Section 2.4 concludes the chapter by providing a summary of the concepts 
introduced. 



2.1 Separation of Concerns 

The evolution of software development techniques has been driven by the 
need to achieve a better separation of concerns: encapsulating features into 
separate entities in order to localise changes and deal with one important 
issue at a time (Dijkstra 1976). In the case of programming languages (cf. 
Fig. 2.1), the first significant step was the development of high-level lan- 
guages to separate the conceptual structure of a program from its machine 
representation. Once high-level languages were developed, features were 
introduced to modularise concerns into coherent behavioural and struc- 
tural abstractions, for instance, procedures and records. The notion of 
objects and classes introduced by object-oriented programming (OOP) 
(Goldberg and Robson 1983; Meyer 1988; Stroustrup 1991; Booch 1994; 
Sun Microsystems 2003) provided further support for separation of con- 
cerns by grouping together the structure and behaviour of an entity and 
hiding its internal representation. The evolution, however, has been incre- 
mental: 
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“The first step towards the management of disease was replacement of demon 
theories and humours theories by the germ theory. That very step, the beginning of 
hope, in itself dashed all hopes of magical solutions. It told workers that progress 
would be made stepwise, at great effort, and that a persistent, unremitting care 
would have to be paid to a discipline of cleanliness. So it is with software engineer- 
ing today.” (Brookes 1995) 

As shown in Fig. 2.1, Aspect- Oriented Programming (AOP) is another 
increment to meet our desire for an improved separation of concerns. It aims 
at modularising concerns which are normally spread across various program 
modules (resulting in a phenomenon known as code tangling (Kiczales, 
Lamping, et al. 1997)) in systems developed using conventional program- 
ming techniques such as object-oriented programming or procedural pro- 
gramming. Since these crosscutting concerns cannot be encapsulated in a sin- 
gle module, their introduction, modification or evolution is an expensive task 
as changes tend to have a broadly scoped, often system-wide, impact. A few 
examples of such crosscutting concerns are memory management, failure 
handling, distribution, persistence, real-time constraints, resource sharing, 
performance optimisation, debugging and synchronisation. 
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Fig. 2.1. Evolution of separation of concerns in programming languages 
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2.2 Addressing Crosscutting Concerns with AOP 

AOP (Kiczales, Lamping, et al. 1997; Elrad, Filman, et al. 2001) employs 
special constructs known as aspects to separate crosscutting concerns. It 
might be argued that patterns (Gamma, Helm, et al. 1995) can help to deal 
with such crosscutting code by providing guidelines for a good structure. 
However, while patterns give a name to certain crosscutting structures, 
unlike AOP they do not capture the concern explicitly in program form. 
Furthermore, patterns are not available or suitable for all cases and mostly 
provide only partial solutions to the code tangling problem. 

Fig. 2.2 uses object-oriented programming as an example (note that 
AOP is not limited to object-orientation) to demonstrate how crosscutting 
concerns lead to code tangling and the effectiveness of AOP in addressing 
such concerns. As shown in Fig. 2.2a, the synchronisation or debugging 
code in a system developed using an object-oriented language, such as Java 
or C+-I-, is spread across the various classes. Fig. 2.2b shows a specific exam- 
ple of this situation in the form of tracing code, often used in debugging, 
spread across the code for classes A and B. Ideally tracing statements should 
be treated as a concern in their own right as they do not contribute to the 
primary application logic implemented by classes A and B. 

Inheritance might be perceived as a solution to the code tangling shown 
in Figs. 2.2a and b because it makes it possible to encapsulate a crosscutting 
concern (e.g., synchronisation) in a superclass. An inheritance-based solu- 
tion, however, simply shifts the code tangling problem to a different dimen- 
sion: extensive invocation and overriding of superclass methods in sub- 
classes. This not only increases the maintenance overhead but also gives rise 
to the fragile base class problem (Mikhajlov and Sekerinski 1998), which 
arises when seemingly acceptable changes to a base class have an adverse 
effect on the subclasses reusing its functionality through inheritance. Fur- 
thermore, mechanisms such as multiple inheritance do not support a single 
unit that affects multiple classes in a non-homogeneous fashion. 

As shown in Fig. 2.2c, in AOP classes are designed and coded (using an 
OO language, e.g., Java or Ch-b) separately from code that crosscuts them 
(in this case debugging and synchronisation code). Aspects, the crosscut- 
ting features, are specified using an AOP technique, e.g.. Aspect J, an aspect 
language for Java ( Aspect J-Team 2003). The AOP technique facilitates: 

• specification of joint points: reference points expressing explicit or 

implicit links between the behaviour and structure of classes and aspects; 
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• composition of the aspect and class code with respect to the join points 
through an aspect weaver. 

The composition can be carried out at different times depending on the 
AOP technique being used. Some AOP techniques support the composi- 
tion to be carried out statically as a phase at compile-time while others sup- 
port load-time or run-time composition (Kiczales, Lamping, et al. 1997; 
Kiczales, Hilsdale, et al. 2001; Pawlak, Seinturier, et al. 2001; Popovici, 
Gross, et al. 2002). 

Fig. 2. 2d shows a tracing aspect, which encapsulates functionality to 
print messages before and after method execution for debugging purposes. 
The method signature, in this case, is obtained through reflective informa- 
tion available for the join point encountered. The aspect will provide trac- 
ing behaviour for all method executions in objects of all classes in the sys- 
tem. The join point can, however, be restricted to match objects of specific 
classes or specific method executions only. 
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Fig. 2.2 a. Crosscutting concerns in an OO language 



class A 




class B 


method ml 




method ml 


print(“ Entering A.ml ”) 




print(‘‘ Entering B.ml ”) 


<method body> 




<method body> 


print(“Leaving A.ml ”) 




print (‘‘Leaving B.ml ”) 


method m2 




method m2 


print(“ Entering A.ml”) 




print(‘‘ Entering B.ml ”) 


< met hod body> 




< method body> 


print(” Leaving A.ml”) 




print(‘‘ Leaving B.ml ”) 



Fig. 2.2b. Tracing statements in an object-oriented application 
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aspect trace 

Join Points: all method 
executions in all objects 

before Join Points 
print (“Entering ” + 
method signature) 
after Join Points 
print (“Entering ” + 
method signature) 



Fig. 2.2 d. A tracing aspect in pseudo code 



Note that, at this stage, the terminology for AOP has not yet been stan- 
dardised. The terms aspect, join point and weaver are used as defacto stan- 
dards though their exact meaning can differ across systems and personal 
perceptions. Efforts are underway to define common semantics for AOP 
techniques. Interested readers are referred to (Masuhara and Kiczales 2003; 
Mehner and Rashid 2003). It is also worth pointing out that the term aspect 
does not imply a particular representation. A general misconception is that 
an aspect should be one large piece of code (in a language like Aspect), for 
instance) encapsulating the crosscutting functionality. This is seldom the 
case. In most cases, traditional separation of concerns and AO abstractions 
work together to modularise a crosscutting concern. Several examples of 









26 2. Aspect-Oriented Programming (AOP) 



this complementarity can be observed in Chaps. 4-6 esp. in the persistence 
frameworks discussed in Chaps. 5 and 6. Sometimes an aspect might con- 
tain a single join point. However, as long as it helps encapsulate a particular 
concern in a systematic fashion, this is not out of sync with good aspect-ori- 
ented programming practices. 

A number of aspect-oriented programming (AOP) approaches have 
been proposed. These range from languages (Kiczales, Hilsdale, et al. 2001) 
and filter-based mechanisms (Bergmans and Aksit 2001) to traversal- ori- 
ented (Lieberherr, Orleans, et al. 2001; Orleans and Lieberherr 2001) and 
reflective techniques (Pawlak, Seinturier, et al. 2001) through to multi- 
dimensional (Tarr, Ossher, et al. 1999) and hybrid (Rashid 2001c) 
approaches. Next, we look at these various sets of techniques in more detail. 



2.2.1 Aspect Languages 

Aspect languages offer constructs additional to those supported by a base 
language (object-oriented, procedural or other) in order to facilitate for- 
mulation of the aspect code separately from the abstractions in the base lan- 
guage. 

Aspect! (Kiczales, Hilsdale, et al. 2001; AspectJ-Team 2003), developed 
at PARC (formerly Xerox PARC), is a statically typed aspect language for 
Java. Programs written with Aspect} run on standard Java Virtual Machines 
(JVMs). The classes are designed and coded (in standard Java) separately 
from the code that crosscuts them. Aspects encapsulate the crosscutting 
code. 

Fig. 2.3 shows the anatomy of an aspect in Aspect}. In the Aspect} pro- 
gramming model, join points are nodes in a simple object call graph at run- 
time, i.e., points at which an object receives a method call or has its fields 
referenced. These include (among others) method/constructor call and 
execution, field get and set, and exception handler execution. 
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Fig. 2.3. Anatomy of an AspectJ aspect and an example aspect in AspectJ 1 .06 



As shown in Fig. 2.3, the definition of an aspect in AspectJ may include: 

• pointcuts, which can be used to express collections of join points and, 
optionally, expose some of the values in the execution context of these 
join points to the aspect code. AspectJ has a series of primitive pointcut 
designators pertaining to the various types of join points supported. 
These include, among others, call for matching a method call, execu- 
tion for method execution, set for when a member variable of the 
object has its value changed, get for when a member variable of the 
object has its value accessed and cf 1 ow for matching join points that fall 
within the context of the control flow of a particular join point. Point- 
cuts can be defined explicitly or implicitly. The example aspect in Fig. 
2.3, for instance, defines an explicitly named pointcut called pci, which 
attaches itself to ca 1 1 s on publ 1 c methods (the wild card indicates 
that the method may have any name) that return void and accept single 
Stri ng arguments in Connecti on objects. Note that the Connect! on 
object that is the target of the call is exposed through the parameter c. 
We will discuss implicit pointcuts when discussing advice constructs 
below. 

• advice, which are constructs defining the behaviour to be executed with 
reference to the join points matched by an explicit named pointcut or an 
implicit pointcut defined by the advice. AspectJ supports three types of 
advice: before advice to execute behaviour before the behaviour of the 
join point is executed, after advice to execute behaviour after the 
behaviour of the join point is executed and around advice which can be 
used to circumvent behaviour at a join point or wrap additional behav- 
iour around it. The example aspect in Fig. 2.3 defines a before advice. 
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which specifies behaviour to be executed before the pointcut defined by 
pci is executed. It also defines an after advice, which specifies behav- 
iour to be executed after calls to the getAddress method in Server 
objects have completed execution. Note that an implicit pointcut exists 
in this case (as opposed to an explicit named pointcut such as p c 1 ) . Note 
that advice behaviour normally applies to the extent (set of all instances) 
of the class unless constrained by using specific values of member vari- 
ables exposed to the advice code. 

• introductions^ also known as inter-type declarations^ to define new opera- 
tions on or introduce additional structure into existing type definitions 
(both classes and interfaces in lava). One can also introduce additional 
extends and implements relationships among types within the con- 
straints of the lava type system, with the exception that it is possible to 
introduce concrete methods into interface definitions. The example 
aspect in Fig. 2.3 introduces a private boolean variable called d1 s- 
abl ed into Connection objects and sets it to false. It also introduces a 
public method called printMessage into both Client and Server 
objects. Note that boolean operators in lava (8c&, ] |, !) can also be used 
for specifying compound pointcuts (formulated through boolean com- 
bination of primitive pointcuts) or excluding specific join points in 
pointcut definitions. 

• ordinary Java members, i.e., member variables and methods. 

For another example of an Aspect! aspect, let us return to the tracing 
aspect in Fig. 2. 2d. Fig. 2.4 shows the tracing aspect from Fig. 2. 2d coded in 
Aspect}. The pointcut methodExecuti ons matches all method executions 
for objects of any class in the system. The matching is carried out on the 
basis of the method signature provided as argument to the execution 
pointcut designator which specifies that the methods to be matched may 
return any value including void (indicated by the first “"^”), belong to 
instances of any class in the system (indicated by the before the “.”), 
have any name (indicated by the after the “.”) and can have zero or 
more arguments (indicated by “(••)”) • 

Although not shown in Figs. 2.3 and 2.4, it is also possible to specify if an 
aspect dominates (has a higher execution priority than) another aspect 
should they influence the same set of join points. Aspect} also supports the 
notion of abstract aspects and pointcuts. Advice behaviour can be written 
in an abstract aspect with reference to an abstract pointcut. A sub-aspect 
can then concretise the pointcut to specify which join points the advice 
should apply to. 
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aspect Tracing { 

pointcut methodExecutionsC ): execution(* *.*(..)); 



beforeC ): methodExecutionsC ) { 

System. out. printlnC'Entering " + 

thisJoinPointStaticPart .getSignatureC )) ; 



} 



} 



afterC ): methodExecutionsC ) { 

System. out. printlnC'Leaving " + 

thisJoinPointstaticPart.getSignatureC )) ; 



} 



Fig. 2.4. A tracing aspect in AspectJ 1 .06 



A weaver is available to merge the aspects and classes with respect to the 
join points. There is additional development support in the form of IDE 
(integrated development environment) extensions to Forte™, Emacs, 
JBuilder™ and Eclipse. AspectJ has also been employed in a number of real- 
life applications to separate distribution and persistence related concerns. 
Interested readers are referred to (Kersten and Murphy 1999; Kienzle and 
Guerraoui 2002; Soares, Laureano, et al. 2002; Rashid and Chitchyan 2003). 

Note that it is not possible to cover the full spectrum of the AspectJ func- 
tionality in this introduction. Interested readers are referred to ( Aspect J- 
Team 2003; Laddad 2003). AOP extensions to other languages have also 
been developed. Aspects (Hirschfeld 2003) and AspectC++ (Spinczyk, 
Mahrenholz, et al. 2003), for example, are AOP extensions to Smalltalk and 
C++ respectively. Similarly, AspectC (Kiczales and Coady 2003) is an 
Aspect J-like AOP extension to C. Aspect languages for several other exist- 
ing programming languages are also available (see http://aosd.net). 



2.2.2 Composition Filters 

The composition filters approach (Aksit, Bergmans, et al. 1992; Bergmans 
and Aksit 2001; Bergmans, Aksit, et al. 2001) exploits the message passing 
mechanism in object-oriented systems to modularise crosscutting con- 
cerns. An object is extended with input and output filters (cf. Fig. 2.5). 
These filters can be of various types, for instance: 

• dispatch filters for delegating messages; 

• wait filters for buffering messages; 
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• error filters for raising exceptions; 

• meta filters for reifying messages. 

Filters trap incoming and outgoing messages that relate to a particular 
crosscutting concern, e.g., synchronisation or real-time behaviour. The 
trapped messages can then be delegated to another object encapsulating this 
behaviour. Such an object can be internal to the filter (Bergmans and Aksit 
2001) or external (Rashid 2001c) as is the case in Fig. 2.5. Note that different 
input and output filters may route messages pertaining to a particular cross- 
cutting concern to the same object encapsulating the aspect code. This is in 
contrast with the example in Fig. 2.5 where filters route messages to different 
objects, which are presumed to encapsulate different concerns. 

The composition filters approach has been implemented for C++, Java 
and Smalltalk (see http://trese.cs.utwente.nl/). The implementation offers 
specific languages such as Sina and ComposeJ to exploit the advantages of 
composition filters in these traditional OO languages. In this sense, the 
implementation can be considered a language extension. However, the 
focus of this section is on the programming model of the composition fil- 
ters approach and not specific languages supporting the model. 




Fig. 2.5. AOP with composition filters 

One can observe several similarities between the composition filters 
model and the aspect language model offered by Aspect} discussed in Sect. 
2.2.1. Input and output filters are similar to poincuts and advice in that they 
specify the messages that are to be matched by the filter and can route these 
messages to other objects for execution of additional behaviour before and 
after the original message if needed. However, there are also some strong 
differences. Filters are attached on a per-instance basis while advice code 
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tends to operate on the extent of the class. The two approaches are, there- 
fore, suited to handling different types of aspectual behaviour, i.e., instance- 
oriented and extent-oriented. Filters are also highly non-invasive. Aspect 
languages such as Aspect}, on the other hand, offer introductions as a means 
to introduce additional code into an existing class. 

It is fairly intuitive to see how the tracing aspect in Fig. 2. 2d may be 
implemented using composition filters. Input and output dispatch filters 
can route all messages received by an object to another object encapsulating 
the tracing behaviour which in turn can display the tracing information 
before the call is allowed to continue to its intended target. 



2.2.3 Adaptive Programming 

Adaptive programming (Mezini and Lieberherr 1998; Lieberherr, Orleans, 
et al. 2001; Orleans and Lieberherr 2001) is a special case of AOP. It aims to 
separate traversal-oriented concerns in a structure-shy fashion. When 
implementing such concerns with conventional approaches, for instance, 
OO techniques, one needs to provide too much information about the 
structure and relationships among classes (whose instances are participat- 
ing in the traversal) within a method in a single class. Alternatively, the 
method needs to be scattered across the various classes. 

With adaptive programming, instead of hard-wiring structural knowl- 
edge paths within the code, this knowledge is separated using a traveral 
strategy. A traversal strategy is a partial, high-level description of how to 
reach the participants of a computation in a class graph. It only specifies 
essential knowledge about how to reach the participants and details of 
intervening nodes in the class graph are abstracted out. Traversal- related 
code is written with reference to the traversal strategy (hence avoiding scat- 
tering it across various classes). Any concrete graphs can then be traversed 
(cf. Fig. 2.6) without having to modify the traversal strategy (as it only pro- 
vides an abstract description of the path between participants and not con- 
crete details of intervening nodes). 
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Fig. 2.6. Separation of traversal-oriented concerns using adaptive programming 

The Demeter tools provide support for adaptive programming in C++ 
and Java (see http://www.ccs.neu.edu/research/demeter/). Similar to the 
discussion in Sect. 2.2.2, the discussion in this section has only focussed on 
the adaptive programming model and not specific language extensions in 
the Demeter tools. 

Let us consider an example of adaptive programming based on traversing 
graphs representing bus routes. Let us assume we wish to calculate the fare 
income for bus travel on various routes between Lancaster City Centre and 
Lancaster University. We want the fare calculation and update algorithm to 
be invoked for each bus stop, i.e., each node in the graph representing a par- 
ticular route. Although there are different bus routes operating between Lan- 
caster City Centre and Lancaster University, their start and end points remain 
the same. In this case, our traversal strategy description, therefore, will be of 
the form: from Lancaster City Centre to Lancaster University. The fare calcula- 
tion algorithm can then be invoked for each node in the concrete graphs that 
satisfy the abstract description in the traversal strategy. Note that, if needed, 
we can include additional constraints in the traversal strategy. For instance, it 
is possible to indicate that fare calculation is only required for routes from 
Lancaster City Centre to Lancaster University through Hala Hill. 

Returning to our tracing aspect example from Fig. 2.2d, the traversal 
strategy can provide an abstract description based on the object call graph. 
If we want to invoke tracing behaviour for all join points in the object call 
graph, the traversal strategy can take the form: from any node to any node. 
Then the tracing behaviour can be invoked for all intervening call graph 
nodes in a concrete object call graph. Note that we could have specified spe- 
cific nodes to be matched, i.e., only method calls. 
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2.2.4 Hyperspaces 

The hyperspaces approach (Tarr, Ossher, et al. 1999) from IBM has its roots 
in earlier work on subject-oriented programming (SOP) (Harrison and 
Ossher 1993). Hyperspaces introduce the notion of multi- dimensional sep- 
aration of concerns by capturing each concern as a partial object model in a 
hyperslice (cf. Fig. 2.7). A hyperslice is declaratively complete - all the ele- 
ments (classes, methods, etc.) used within the hyperslice are declared in it 
(though not necessarily implemented). This makes it possible to observe 
how various concerns overlap and cut across each other - since there is no 
dominant base decomposition any set of concerns can be used as a base to 
observe the effect of another set of concerns on it. As shown in Fig. 2.7, the 
hyperslices are composed into a hypermodule by means of declarative com- 
position rules. The hypermodules thus produced can themselves serve as 
hyperslices in more complex hypermodules. Note that the hyperspaces 
approach also supports on-demand remodularisation of legacy code. 

The Hyper/J tool (Ossher and Tarr 2001) provides support for using 
hyperspaces in Java (see http://www.research.ibm.com/hyperspace/). 

Similar to the discussion in Sects. 2.2. 1-3, the implementation of the 
tracing aspect from Fig. 2.2d is fairly intuitive using hyperspaces. The 
tracing behaviour can be specified in a class in a separate hyperslice. The 
Hyper/J composition specification can then be used to bracket the method 
executions (in other hyperslices) to be traced with the tracing code. 



Hypermodule 



Composition Rule e.g. Merge classes in different 
hyperslices by name 




Slice 2 






Slice 3 



A 



Fig. 2.7. AOP with Hyperspaces 
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2.2.5 Reflective Approaches 

Since the early days of AOP, its relationship with reflection (Smith 1982) 
has been debated. There are two main reasons for this: 

1. Reflection is a separation of concerns mechanism, supporting separation 
of base-level concerns from meta-level concerns. Consequently, it is 
possible to modularise some crosscutting concerns using reflective tech- 
niques. 

2. The AOP mechanisms to introduce additional behaviour into the con- 
trol flow of a program, for instance, before and after advices in 
Aspect!, are very similar to before and after constructs in reflective 
systems such as CLOS (Kiczales, des Rivieres, J., et al. 1991). 

The relationship is now becoming clearer. Reflection is a general-pur- 
pose separation of concerns mechanism, which provides features that may 
be employed for separation of crosscutting concerns. AOP, on the other 
hand, focuses specifically on systematic modularisation of crosscutting 
concerns. Therefore, reflective techniques, when used to separate crosscut- 
ting concerns, can be categorised as AOP. For instance, the OpenORB sys- 
tem (Blair, Coulson, et al. 2001) uses runtime reflection to support separa- 
tion of some concerns relating to distribution. (Welch and Stroud 2003) 
discuss the use of the Kava meta-object protocol (Welch and Stroud 2001) 
to remodularise security concerns in an existing application. The GOODS 
system (Knizhnik 2003) discussed in Sect. 4.2.3 employs a meta-object pro- 
tocol to modularise its transaction model and locking policies. The persis- 
tence framework discussed in Chap. 6 also provide a good example of the 
use of reflection in aspectising crosscutting concerns. 

Reflective approaches also provide a suitable means to implement 
dynamic AOP systems. Aspects (Hirschfeld 2003) uses dynamic wrappers 
and the meta-object protocol in Smalltalk. Java Aspect Components (JAC) 
(Pawlak, Seinturier, et al. 2001) is a dynamic AOP system for Java. It also 
employs dynamic wrappers and a reflective architecture based on the Jav- 
assist load-time meta-object protocol to support dynamic aspect composi- 
tion and resolution of composition anomalies at runtime. JAC also offers a 
distributed join point specification mechanism for aspects that may span 
multiple hosts. Lasagne (Truyen, Vanhaute, et al. 2001) is another dynamic 
AOP system based on a reflective architecture. It supports context sensitive 
composition of aspects and has been employed in the implementation of an 
adaptive Object Request Broker (Truyen, Joergensen, et al. 2000). 
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2.2.6 Hybrid Approach 

The hybrid AOP approach (Rashid 2001c) is based on the observation that 
while the various AOP approaches are supplementary - all these approaches 
form suitable candidates for separation of crosscutting concerns in a system 
- they are also complementary. In some scenarios one approach can be more 
suitable as compared to the others. For instance, composition filters are very 
effective in implementing concerns involving message interception and exe- 
cution of actions before and after executing a method. Their key character- 
istic is the ability to operate at instance granularity and attachment on a per- 
instance basis. Adaptive programming, on the other hand, is highly suitable 
for expressing concerns which involve separation of behaviour from object 
structure. It is very effective in situations where the behaviour may be writ- 
ten against a partial specification of a class diagram or a generic specification 
of the structure of objects (not relating to information specific to individual 
instances). Aspect languages and weavers are most suitable in implementing 
concerns that need to be explicitly represented using linguistic constructs. 
Hyperspaces and reflective approaches offer specific strengths in remodular- 
isation of legacy systems and applications requiring dynamic reconfigura- 
tion of aspects respectively. 

The hybrid AOP approach, therefore, offers: 

• a suitability matrix (cf Fig. 2.8), based on the above observations, in 
order to identify the most suitable AOP technique to map a particular 
aspect to the implementation space; 

• composition mechanisms to weave together aspects implemented using 
different AOP techniques. 
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• • • 



Fig. 2.8. Hybrid approach to AOP 
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The hybrid approach has been used to implement customisable evolu- 
tion concerns in the SADES object database evolution system (discussed in 
more detail in Chap. 4) using three AOP techniques: composition filters, 
adaptive programming and a declarative aspect language. Composition of 
aspects in the three techniques in SADES has been facilitated by identifying 
concerns that build upon the functionality offered by other concerns. The 
latter are implemented in lower system layers exposing their functionality 
to the former which reside in higher system layers. In addition to the lay- 
ered composition, the composition filters mechanism has been employed 
to integrate the declarative aspect language and its weaver into the system. 



23 Aspect-Oriented Software Development 

After initial successes at the programming level, aspect-orientation focus is 
now expanding to the earlier stages of software development, leading to the 
term aspect-oriented software development (AOSD). (Andrews 2001; 
Douence, Motelet, et al. 2001; Sihman and Katz 2002) propose formal 
models for aspect-oriented systems. The hyperspaces model (Tarr, Ossher, 
et al. 1999) and Cosmos (Sutton and Rouvellou 2002) support multi- 
dimensional separation of concerns throughout the software life cycle. The 
early aspects model (Rashid, Sawyer, et al. 2002; Rashid, Moreira, et al. 
2003) supports modularisation, composition and traceability of require- 
ments level aspects throughout the software life cycle and makes it possible 
to establish early trade-offs. The XBel framework (Cheng 2003) offers sim- 
ilar decision support in the presence of inconsistent viewpoints. (Grundy 
1999) proposes a characterisation of diverse requirements-level aspects of a 
system that each component provides to end users or other components. 
(Dingwall- Smith and Finkelstein 2002) support goal-oriented require- 
ments engineering by using aspects as a means to monitor system goals at 
run-time. (Tekinerdogan 2000) focuses on synthesis-based identification 
and composition of architectural aspects while (Kazman, Klein, et al. 1998) 
propose a model for identifying architectural trade-offs by building quali- 
tative and quantitative models of competing quality attributes. In (Andrade 
and Fiadeiro 2002), a set of modelling primitives based on the separation 
between configuration, coordination and computational aspects of systems 
is proposed. These primitives allow for business rules to be externalised and 
made explicit in system architectures in order to improve evolvability and 
adaptability. The primitives are supported at the programming level 
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through an extension of Java with coordination mechanisms (Lano, Fia- 
deiro, et al. 2002). 

At the design level most of the AOSD work has focussed on UML and its 
extensions. The composition patterns approach (Clarke and Walker 2001a) 
aims at separating reusable patterns of crosscutting behaviour that hold 
regardless of the concerns they cut across. (Grundy 2000a) categorises com- 
ponents on the basis of their contribution to the various aspects while 
(Suzuki and Yamamoto 1999b) propose aspect-oriented extensions to 
UML and an XML based aspect description language to facilitate aspect 
exchange. (Clark, Evans, et al. 2003) propose a meta-modelling approach 
and its application to UML 2.0 submissions. Different, reusable aspects of 
modelling languages are separated using package templates. The templates 
are instantiated in a particular context and composed using package exten- 
sions to form language fragments. These fragments can, in turn, be com- 
posed to form languages. 



2.4 Conclusion 

This chapter introduced the problem of crosscutting concerns and how 
AOP techniques provide a systematic means to modularise such concerns. 
Some key AOP approaches namely, aspect languages, composition filters, 
adaptive programming, hyperspaces, reflective techniques and the hybrid 
approach, were outlined and their programming models discussed. The 
discussion offers an insight into how crosscutting concerns can be modu- 
larised using the features offered by each technique, hence providing a basis 
for the aspectisation of crosscutting concerns described in the following 
chapters. The description also allows the reader to contrast the variety of 
techniques available and their respective strengths in modularising partic- 
ular types of crosscutting concerns. 

Techniques for modularising crosscutting concerns at software develop- 
ment stages preceding implementation were also reviewed. This reflects the 
growing interest in aspect-oriented software development techniques. A 
number of aspect-oriented approaches are available and this chapter has 
barely scratched the surface by introducing some of the key techniques. 
Readers are referred to http://aosd.net for information on other approaches. 

While aspect-oriented techniques provide additional support to develop 
systems with a higher degree of modularity, evolvability, maintainability and 
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adaptability, they are certainly not the silver bullet (Brookes 1995) of soft- 
ware engineering. They are another step, a significant one, forward in our 
quest for a better separation of concerns. The following chapters discuss how 
we can exploit this additional support for separation of concerns to develop 
database systems and applications that are more evolvable, maintainable, 
extensible and adaptable in the face of changing requirements. They also 
highlight how database systems can support developers using aspect-ori- 
ented techniques by providing support for asset management. 




3. Crosscutting Concerns in Database 
Systems 



Chapter 2 introduced the problem of crosscutting concerns in software sys- 
tems. This chapter discusses crosscutting concerns specific to database sys- 
tems and how their tangling with other concerns adversely affects custom- 
isability, extensibility, maintainability and evolvability. Crosscutting 
concerns in database systems can be categorised as: 

• DBMS-level crosscutting concerns 

• Database-level crosscutting concerns 

The former, discussed in Sect. 3.1, relate to the software system manag- 
ing the database. Conceptually they are not very different from crosscutting 
concerns in other software systems apart from some domain specific prop- 
erties. Sections 3. 1.1 -3 discuss some concrete examples of such crosscutting 
concerns namely, the instance adaptation approach, the schema evolution 
approach and the transaction model. Some other crosscutting concerns at 
the DBMS level are listed in Sect. 3.1.4. 

Crosscutting concerns at the database level, discussed in Sect. 3.2, relate 
to the data and meta-data (e.g., the schema) residing in the database. They 
are persistent as they are spread across persistent entities. This persistent 
nature must be taken into account by modularisation techniques. Sections 
3.2. 1-3 provide three concrete examples of such crosscutting concerns. 
These include links among persistent entities, versioning information and 
the instance adaptation approach. Some other database level crosscutting 
concerns are listed in Sect. 3.2.4. Section 3.3 concludes the discussion in the 
chapter. 
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3.1 Crosscutting Concerns at DBMS Level 

Trade-offs between modularity and efficiency, and granularity of services 
and the number of interservice relationships result in DBMS designs which 
lack customisability. This section discusses the problems faced when trying 
to achieve a high degree of customisability at the DBMS level in monolithic, 
layered and component-based designs. These problems arise due to the 
crosscutting nature of customisable features. 

The structure of a monolithic DBMS is shown in Fig. 3.1a. For simplifi- 
cation only three key components: the storage manager, the transaction 
manager and the schema manager are shown. As shown in the figure, the 
various components are tangled together. While such a closely woven 
implementation provides good performance/efficiency, customisation is an 
expensive and difficult task as changes to the various components are not 
localised. Changing the indexing or clustering technique employed by the 
storage manager, the instance adaptation approach employed by the 
schema manager or the transaction model used by the transaction manager, 
for example, at either compile-time or run-time can have a large ripple 
effect on the whole system. Layered architectures (Haerder and Reuter 
1983; Ramakarishnan 1997) only provide partial solutions to the customi- 
sation problem and only at a coarse granularity. The intra-layer and inter- 
layer interactions in such designs simply shift the code tangling problem to 
a different dimension (Pulvermueller, Speck, et al. 2000). In the layered 
architecture proposed by (Haerder and Reuter 1983), for example, the con- 
currency control components are spread across two different layers. Cust- 
omisation of the lock management or recovery mechanisms (residing in the 
lower layer) have a knock-on effect on the transaction management com- 
ponent (residing in the higher layer). 

The customisation approach employed by most commercial (esp. rela- 
tional and object-relational) DBMSs is shown in Fig. 3.1b. In this approach 
the DBMS design is still largely monolithic (to improve performance). Spe- 
cial customisable points similar to hotspots in OO frameworks (Fayad and 
Schmidt 1997) allow custom components to be incorporated into the sys- 
tem. Examples of such components include Informix DataBlades (Infor- 
mix White Paper, 1998), Oracle Data Cartridges (Banerjee, Krishnamurthy, 
et al. 2000) and DB2 Relational Extenders (Debloch, Chen, et al. 2000). 
However, customisation in these systems is limited to introduction of user- 
defined types, functions, triggers, constraints, indexing mechanisms and 
predicates, etc. Customisations such as introduction of new index types, for 
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example, trigger the need to adapt the concurrency control mechanism, 
particularly the lock manager, for performance reasons. Changes to the 
lock manager in turn affect logging, recovery, etc. (Dittrich and Geppert 
2000 ). 



Custom Components 




Fig. 3.1 a-d. Crosscutting in existing DBMSs: (a) a monolithic DBMS (b) a DBMS with 
plug-in components (c) a component-based DBMS (d) a component (schema manager) 
in a component-based DBMS 

Fig. 3.1c shows the modular, component-based implementation 
employed by systems such as KIDS (Geppert and Dittrich 1995; Geppert, 
Scherrer, et al. 1997), Navajo (Bobzin 2000) and Objectivity (Guzenda 
2000). Again, only three key components: the storage manager, the transac- 
tion manager and the schema manager are shown for simplification. Such 
a design provides effective customisability. For example, the transaction 
manager (or any other component) can be exchanged with the ripple effect 
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mainly limited to the glue code. However, in order to strike the right bal- 
ance between modularity and efficiency the design of the individual com- 
ponents is not highly modular. As shown in Fig. 3. Id, the modularity of the 
individual components is compromised to preserve both modularity and 
efficiency of the DBMS. As a result the coarse-grained component, the 
DBMS, is customisable. However, customisability at a finer granularity (i.e., 
the components forming the DBMS) is expensive as design at this level is 
largely monolithic - the customisation problem simply moves to a different 
granularity. Such customisation would be cost-effective if changes at the 
fine granularity were localised without compromising the system perfor- 
mance obtained through closely woven components, i.e., both modularity 
and efficiency need to be preserved. Even if componentisation is applied at 
a fine granularity cross-component constraints introduce tangling among 
these fine-grained components. 

Note that database systems based on component architectures such as 
OLE DB (Blakeley 1996; Microsoft 1999) and CORBA (OMG 2003) also 
offer customisation support at a coarse granularity only and hence suffer 
from the same shortcomings as component-based DBMSs discussed above. 

Next, we look at some concrete examples of crosscutting concerns at the 
DBMS level. 



3.1 .1 Instance Adaptation Approach 

Instance adaptation is the process of simulated or physical conversion of 
objects across compatible class definitions upon schema evolution in object 
databases. Note that instance adaptation is a concern at both the DBMS 
level and the database level (cf. Sect. 3.2.3). It is, therefore, important to 
clarify the distinction between the instance adaptation approach and an 
instance adaptation routine. The former is a DBMS level concern and is the 
code that forms part of the schema manager. It defines the instance adap- 
tation strategy for the system, for instance, simulated conversion or physi- 
cal conversion. An instance adaptation routine, on the other, hand is the 
code specific to a class or its historical representation (depending on 
whether change histories are maintained). It is, therefore, a database level 
concern and defines adaptation semantics for instances of the particular 
class definition. The instance adaptation approach specifies the type (and at 
times structure) of the instance adaptation routines to be used, e.g., error 
handlers (Skarra and Zdonik 1986), update/backdate methods (Monk and 
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Sommerville 1993) or transformation functions (Ferrandina, Meyer, et al. 
1995) and, upon detection of an interface mismatch between a class defini- 
tion and the object accessed using it, invokes the appropriate routine with 
the correct set of parameters. 

Organisations have highly specialised evolution requirements with refer- 
ence to instance adaptation (Rashid 2000a; Rashid, Sawyer, et al. 2000). For 
one organisation it might be sufficient that object conversion is simulated 
while for another physical conversion may be essential. The choice is dic- 
tated by “local” organisational needs and at times custom variations of 
standard instance adaptation models can be required. The choice of 
instance adaptation approach may even vary from one application to 
another within the same organisation. 

Traditionally, the instance adaptation approach in object database sys- 
tems is tangled with other parts of the schema manager, for instance, the 
evolution model and change history manager (cf. Fig. 3. Id). Customising 
the instance adaptation approach in such a system, for example, requires 
exchanging the whole schema manager component as changes to the 
instance adaptation approach are not localised. This also limits possibilities 
for dynamic customisation. Application specific customisation of the 
instance adaptation approach, for example, requires dynamically exchang- 
ing the whole schema manager component which is an expensive task. Fur- 
thermore, a change to the instance adaptation approach can have a large 
ripple effect on the instance adaptation routines at the database level (cf. 
Sect. 3.2.3). 



3.1.2 Schema Evolution Model 

(Sjoberg 1993) provides measurements of the frequency and extent of 
changes to the conceptual structure of a database. The need for these vari- 
ations (evolution) arises due to a variety of reasons, e.g.: 

• to correct mistakes in the database design; 

• to add new features during incremental design; 

• to reflect changes in the structure of the real world artefacts modelled in 
the database. 

Let us consider evolution models in object databases as an example. 
These models can be divided into four categories: 
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• Schema modification (Banerjee, Chou, et al. 1987; Banerjee, Kim, et al. 
1987; Fishman 1987; Li and McLeod 1994; Ferrandina, Meyer, et al. 
1995; Peters and Ozsu 1997; Dmitriev 1998), where the database has one 
logical schema to which all changes are applied. No historical represen- 
tations of class definitions are kept. 

• Schema versioning (Kim and Chou 1988; Lerner and Habermann 1990; 
Odberg 1992; Ra and Rundensteiner 1997), which allows several ver- 
sions of one logical schema to be created and manipulated indepen- 
dently. Change histories are maintained at a coarse granularity. 

• Class versioning (Skarra and Zdonik 1986; Bjornerstedt and Hulten 1989; 
Monk and Sommerville 1993; Rashid, Sawyer, et al. 2000), which keeps 
different versions of each type and binds instances to a specific version 
of the type. Change histories are maintained at a fine granularity. 

• Hybrid models such as context versioning (Andany, Leonard, et al. 1991), 
which is based on versioning partial, subjective views of the schema or 
those based on superimposing one model on another, e.g., (Benatallah 
and Tari 1998; Rashid 2001a). 

Traditionally, an object database management system offers the main- 
tainer one particular schema evolution model coupled with a specific 
instance adaptation mechanism. For instance, CLOSQL (Monk and Som- 
merville 1993) is a class versioning system employing dynamic instance con- 
version as the instance adaptation mechanism; ORION (Banerjee, Chou, et 
al. 1987) employs schema modification and transformation functions; 
ENCORE (Skarra and Zdonik 1986) uses class versioning and error handlers 
to simulate instance conversion. It was argued in Sect. 3.1.1 that such 
“fixed” instance adaptation approaches do not serve local organisational 
needs effectively. The same is true for the evolution model. For one organ- 
isation (or application) it might be inefficient to keep track of change his- 
tories, hence making schema modification the ideal evolution model. For 
another organisation (or application) maintenance of change histories and 
their granularity might be critical. In some cases, custom variations of exist- 
ing approaches might be desirable. 

As shown in Fig. 3. Id, the evolution model tends to be tangled with other 
parts of the schema manager, e.g., the instance adaptation approach and the 
change history manager. Consequently, any change to the evolution model 
(whether carried out offline or dynamically) can have a large ripple effect on 
the schema manager. Furthermore, customisation of the evolution model is 
made virtually impossible by the fact that most database management sys- 
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terns do not distinguish between the schema evolution model and the 
schema implementation model. With the exception of the TSE system (Ra 
and Rundensteiner 1997), the schema evolution model is also used as the 
implementation model. This implies that customisation of the evolution 
model would invalidate the whole schema and, in fact, the whole database. 



3.1.3 Transaction Model 

Transactions transfer the database from one consistent state to another. A 
number of transaction models have been proposed. The classic flat trans- 
action model enforces the ACID (atomicity, consistency, isolation and dura- 
bility) (Gray and Reuter 1993; Elmasri and Navathe 2000) properties of 
transactions operating on the database. Each transaction is primitive with no 
sub-transactions. A transaction in the nested transaction model (Moss 1982; 
Moss 1987), in contrast, is a tree structure with a root or top-level transac- 
tion. Nested within the root are one or more sub -transactions (also known 
as child transactions). Nested transactions are useful when a transaction is 
required to hide intermediate results. This allows the usual rollback of per- 
sistent data to the state at the beginning of the transaction. However, nesting 
of transactions allows rollback of persistent data to some point after the 
beginning of the top-level transaction. Top-level transactions satisfy the 
ACID properties with respect to other top-level transactions while child 
transactions preserve atomicity, consistency, isolation and durability with 
respect to each other. Other transaction models, e.g., cooperative transac- 
tions (Zhang, Kambayashi, et al. 1999) relax the basic ACID properties to 
allow a transaction to observe the internal state of other transactions. 

For traditional data-oriented, record processing database applications, 
the basic flat transaction model or the nested transaction model tends to be 
satisfactory. Advanced applications such as collaborative design or develop- 
ment environments, on the other hand, are better served by a cooperative 
transaction model (often one supporting long transactions (Katz 1990; 
Santoyridis, Carnduff, et al. 1997)) permitting visibility of changes made by 
a transaction before it commits. There can be other application specific 
properties desirable of a transaction model, for instance, whether a new 
transaction spawned from an existing one is started as a new thread or as 
part of an existing one (Dittrich, Gatziu, et al. 1995). Similarly, it might be 
desirable that a transaction may commit only if another transaction has 
committed (or aborted) (Dittrich, Gatziu, et al. 1995). 
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Traditionally, a DBMS offers one particular transaction model - basic 
flat or nested transactions or a set of slight variations of such a basic model 
- to the applications. The supported variations, if any, cannot cater for the 
needs of all applications. Customisation of the transaction model to suit the 
needs of a particular application (not satisfied by the basic model or its vari- 
ations) is difficult and expensive as the transaction model is intertwined 
with other concerns such as cache management and synchronisation of 
persistent and transient state. 



3.1 .4 Other Crosscutting Concerns at DBMS Level 

Sections 3. 1.1-3 provided some detailed examples of crosscutting concerns 

at the DBMS level and how these inhibit adaptability and evolution. Other 

examples of crosscutting concerns at the DBMS level include: 

• version management policy and workgroup support features, which are 
intertwined with the transaction model, the storage manager, the access 
manager and the evolution model (depending on whether versioning of 
schema elements is supported); 

• security and access control policies, which overlap with the version man- 
agement and workgroup support policies, the storage and access manag- 
ers and the evolution model; 

• cache management and object synchronisation policies, which have a 
crosscutting relationship with the transaction model and the recovery 
mechanism; 

• strategy for lazy evaluation and resolution of transient references to per- 
sistent objects, a concern intertwined with cache management and the 
access manager. 



3.2 Crosscutting Concerns at Database Level 

This section provides examples of concerns that cut across data or meta- 
data residing in the database and lead to tangled, inflexible representations 
that are costly to evolve. The examples also demonstrate how customisation 
of features, such as the instance adaptation approach, at the DBMS level has 
a direct impact on entities already residing in the database. It is shown that 
existing database systems provide little support for localising the impact (at 
the database level) of any changes propagated due to customisation at the 
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DBMS level. As a result propagation of customisation results in an 
increased maintenance overhead at the database level. 



3.2.1 Links Among Persistent Entities 

A number of relationships can exist among entities - objects, meta-objects 
(class and attribute definitions, etc.) and meta-classes - residing in an 
object database. Examples of these relationships are: 

• association and aggregation relationships among objects; 

• version derivation links among object or class versions; 

• inheritance relationships among classes (or their versions); 

• scoping relationships between classes and their members. 

Traditionally object databases use attributes to embed relationship 
information within the entities hence spreading the relationships across 
them. Fig. 3.2a shows part of the meta-class in a system embedding inher- 
itance links within class meta-objects. Each class meta-object maintains col- 
lections of references to class meta-objects forming its superclasses and sub- 
classes. Such a structure introduces the evolution problem at the meta- 
object level. When any inheritance relationships are modified correspond- 
ing attributes in the affected meta-objects need to be updated to reflect the 
change. Modifying the structure of meta-classes and introduction/removal 
of existing classes is very expensive. This reduces the extensibility and main- 
tainability of the system. 



Meta-class Class 



Collection of 
references to 
subclass 
meta-objects 



Collection of 
references to 
superclass 
meta-objects 



Fig. 3.2 a. Meta-class structure showing inheritance relationship implementation in 
existing systems 
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Fig. 3.2 b. Modification of inheritance relationships upon introduction of a non-leaf 
class meta- object in existing systems 



Fig. 3.2b shows an example schema evolution scenario depicting the 
meta-objects in such a system prior to the introduction of a non-leaf class. 
The scenario is based on a case study carried out at an adult education insti- 
tution in the UK. The classes Person, Tutor, Coordinator, Exam Officer, 
Moderator and Principal already exist in the system while the class Staff is 
the non-leaf class being introduced into the system. Upon introduction of 
the meta-object for class Staff, all the references to subclass meta-objects 
will have to be removed from the Person meta-object and all the subclass 
meta-objects will have to be updated to remove the reference to Person in 
their respective collections of superclass references. A reference to the Per- 
son meta-object will have to be added to the superclasses collection and ref- 
erences to older subclasses of Person will have to be added to the subclasses 
collection in the meta- object. A reference to the Staff met^-object will 

have to be added to the subclasses collection (not shown in Fig. 3.2b) in Per- 
son and to the superclasses collection in each of its former subclasses. The 
number of entities affected upon modification of a connection is m+n 
where m and n represent the number of participating entities at each edge 
of the relationship (in this case superclasses edge and subclasses edge). This 
example demonstrates that information about links among entities cuts 
across them. 



3.2.2 Versioning Information 

Some applications require hierarchical organisation of data based on 
change histories. For instance, versioning of objects (Chou and Kim 1986; 
Katz, Chang, et al. 1986; Klahold, Schlageter, et al. 1986; Ecklund, Ecklund, 
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et al. 1987; Ketabchi and Berzins 1987; Dittrich and Lorie 1988; Katz 1990; 
Oussalah and Urtado 1997; Santoyridis, Carnduff, et al. 1997) is often sup- 
ported to service collaborative computer-aided design environments. Simi- 
larly, class versioning is often used as a means for schema evolution in object 
databases (Skarra and Zdonik 1986; Bjornerstedt and Hulten 1989; Monk 
and Sommerville 1993; Rashid, Sawyer, et al. 2000). 




Fig. 3.3. Versioning information crosscutting versioned entities 



Versioning information is often embedded within the versioned entities 
(cf. Fig. 3.3). Consequently, any changes to the versioning information at 
the DBMS level affect the versioned entities. Even if version derivation 
graphs (Loomis 1992) are used, the semantics of class and object versioning 
differ. The version management behaviour has to refer to different sets of 
graphs. Furthermore, the traversal and update semantics form part of the 
behaviour of the nodes forming the class and object version derivation 
graphs. Customisation of such traversal or update behaviour, for instance, 
to employ a more efficient strategy, can have an impact that is likely to span 
all the class and object version derivation graphs. 



3.2.3 Instance Adaptation Routines 

Customisation of instance adaptation in existing object database evolution 
systems is expensive because they introduce the instance adaptation rou- 
tines directly into the class versions upon evolution. Often the same adap- 
tation routines are introduced into a number of class versions. Conse- 
quently, if the behaviour of a routine needs to be changed maintenance has 
to be performed on all the class versions in which it was introduced. If the 





50 3. Crosscutting Concerns in Database Systems 



instance adaptation approach at the DBMS level is customisable, any such 
customisation or adoption of a new strategy might trigger the need for 
changes to all or a large number of versions of existing classes. Further- 
more, there is a high probability that a number of adaptation routines in a 
class version will never be invoked as only newer applications will attempt 
to access properties and methods unavailable for objects associated with the 
particular class version. 

The above shortcomings can be demonstrated by considering instance 
adaptation in ENCORE (Skarra and Zdonik 1986) which employs a simu- 
lation-based approach for the purpose. As shown in Fig. 3.4, applications 
access instances of a class through a version set interface which is the union 
of the properties and methods defined by all versions of the class. Error 
handlers are employed to trap incompatibilities between the version set 
interface and the interface of a particular class version. These handlers 
ensure that objects associated with the class version simulate the version set 
interface, i.e., the presence of missing attributes or methods for an object. 
As shown in Figs. 3.4b and c, error handlers for missing information are 
introduced into all the former versions of a class upon each additive change: 
change which modifies the version set interface. If the behaviour of the 
address handler in Fig. 3.4c needs to be customised maintenance has to be 
carried out on all the former class versions. This reflects the crosscutting 
nature of instance adaptation routines. 

The example in Fig. 3.4 describes a fairly simple evolution scenario. In a 
more complex scenario, introduction of error handlers into former class 
versions is a significant overhead as, over the lifetime of a database, a sub- 
stantial number of hierarchically related class versions will exist prior to the 
creation of a new one. If the behaviour of some handlers needs to be 
changed maintenance will have to be performed on all the hierarchically 
related class versions in which the handlers were introduced. Similarly, 
changes to the instance adaptation approach or moving to a different strat- 
egy will be very expensive too and will trigger changes to a large number, if 
not all, of the class versions as all the error handlers will need to be removed 
and adaptation routines (e.g., update/backdate methods (Monk and Som- 
merville 1993)) required by the new adaptation approach introduced. 
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Fig. 3.4 a-c. Instance adaptation routines in ENCORE: (a) before evolution (b) upon 
an additive change (c) upon another additive change 



3.2.4 Other Crosscutting Concerns at Database Level 

Several other concerns also cut across the data and meta-data residing in 
the database. These include: 

• access rights on data; 

• constraints on data; 

• data representation. 

All the above concerns relate to or affect multiple tables or objects in a 
database, a crosscutting effect. 



3.3 Conclusion 

This chapter employed several concrete examples to demonstrate how 
crosscutting concerns affect the modularity of database systems, at both the 
DBMS level and the database level. It was argued that this has direct conse- 
quences in terms of increasing customisability, adaptability and evolution 
costs. The knock-on effect of customising DBMS level concerns on data- 
base level concerns was also discussed. Although most of the examples were 
based on object database systems, the discussion can be generalised to other 
types of database systems. For instance, some of the DBMS-level concerns. 
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such as the transaction model, security and access control policies (and 
need for their customisation), exist in all types of database systems. Simi- 
larly, most of the evolution concerns discussed can be generalised to 
include complex data structures and their instances in object-relational 
database systems. 

In Chap. 2 the effectiveness of AOP in addressing crosscutting concerns 
was described making it an obvious candidate for modularising such con- 
cerns in database systems. Chapter 4 discusses how AOP can be employed 
to address the concerns highlighted in this chapter. 




4. Applying AOP in Database Systems 



The discussion in Chap. 3 demonstrated that crosscutting concerns in data- 
base systems inhibit cost-effective customisation at the DBMS level and the 
database level and propagation of customisation from the DBMS level to the 
database level. Chapter 2, on the other hand, described the effectiveness of 
aspect- oriented techniques to localise changes to crosscutting features. This 
chapter discusses how aspect- orientation can be employed to achieve cost- 
effective customisation without compromising the performance or smaller 
number of interservice relationships in tightly woven implementations. 

Section 4.1 presents a model of AOP in database systems. Sections 4.2 and 
4.3 discuss object database systems that are concrete realisations of this 
model to modularise crosscutting concerns at the DBMS level and database 
level respectively. The discussion focuses on aspectisation of the crosscutting 
concerns highlighted in Chap. 3 namely, instance adaptation approach, 
schema evolution model, transaction model, links among persistent entities, 
versioning and instance adaptation routines. Other crosscutting concerns 
listed in Sects. 3.1.4 and 3.2.4 are not discussed, as most of them are not cur- 
rently implemented by any of the AODBs available. The propagation of cus- 
tomisation from DBMS level to database level is discussed in Sect. 4.4. Sec- 
tion 4.5 presents a quantitative evaluation of the cost-effectiveness of the 
AOP approach when employed for object database evolution. Section 4.6 
summarises and concludes the discussion in the chapter. 



4.1 A Model for AOP in Database Systems 

As shown in Fig. 4.1a, aspects can be used to separate the crosscutting cus- 
tomisable features from non-customisable features and core functionality 
of a database component. Note that the term “component” is used here in 
its most generic sense and hence incorporates monolithic DBMSs, the 
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DBMS or plug-in components in a plug-in based DBMS, and coarse or 
fine-grained components in a component-based DBMS. It also incorpo- 
rates entities (e.g., objects, meta-objects, meta-classes in an object database; 
relational tables in a relational database; complex types and their instances 
in an object-relational database) residing in the database. Changes to the 
features encapsulated by aspects are localised making it possible to achieve 
a high degree of customisability. Both minor and major customisations can 
be carried out in a cost-effective fashion regardless of component granular- 
ity. Changes are automatically propagated during weaving or reweaving (at 
compile-time or run-time). It is also possible to separate customisable fea- 
tures at a coarse granularity and propagate them to finer granularities as 
one aspect can serve more than one component if the same customisable 
feature exists in all of them. Since cross-component constraints are cross- 
cutting in nature aspects can also be used to encapsulate them. 

As shown in Fig. 4.1b, the aspect-oriented approach makes customisa- 
tion possible at both compile-time and run-time provided the AOP tech- 
nique and its composition mechanism, for instance, an aspect language and 
its associated weaver, support both static and dynamic aspects. As shown in 
the figure. Aspect ], Aspect 2 and Aspect 3 can be customised or exchanged 
with localised changes before the compile-time weaving process weaves 
them with the rest of the component. Aspects encapsulating features that 
need customisation at compile-time only are merged with the rest of the 
component at compile-time and do not exist at run-time. This reduces the 
overhead of managing a large number of aspects and their weaving/reweav- 
ing at run-time. Aspect 3 in Fig. 4.1b is an example of such an aspect. 

Aspects encapsulating features which require customisation at run-time 
have a lifetime extended beyond compile-time. They exist at run-time and 
may even outlive the program execution (cf Chap. 5). Aspect 1 and Aspect 
2 in Fig. 4.1b are examples of such aspects. Aspect 1 encapsulates a feature 
which is customised at run-time but not very frequently. Aspect 2, on the 
other hand, encapsulates a feature which is frequently customised at run- 
time. In the example. Aspect 1 is woven at compile-time and rewoven at 
run-time only when it is customised (rarely). The weaving of Aspect 2 on 
the other hand is left to run-time. As shown by the dotted line around the 
woven feature (encapsulated hj Aspect 2) , Aspect 2 is woven and rewoven at 
run-time frequently due to extensive dynamic customisation. It should be 
noted that the scenario in Fig. 4.1b is just an example. Aspect 2 could have 
been woven at compile-time and still frequently customised at run-time. 
The example simply demonstrates that it is not necessary to weave all the 
dynamically customisable features at compile-time and vice versa. 
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It might be argued that the aspect-oriented approach simply shifts the 
complexity of the customisation process to the aspect composition mecha- 
nism. This might be true if for each customisable feature a specifically 
designed aspect language and weaver were being used. Since most DBMSs 
are developed using general-purpose programming languages, a general- 
purpose aspect language similar to Aspect} (AspectJ-Team 2003) and its 
associated weaver (or any AOP technique supporting the general purpose 
programming language) will be sufficient to provide a woven solution 
which is both performance optimised and correct. 
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Fig. 4.1a. Separation of crosscutting customisable features in database systems using 
aspects 
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4.2 AOP at DBMS Level 

This section discusses existing systems employing AOP to modularise 
crosscutting concerns at the DBMS level namely, instance adaptation 
approach, schema evolution model and transaction model. The discussion 
is derived from three AODBs: SADES (Rashid and Sawyer 1999; Rashid 
2000a; Rashid and Sawyer 2000a; Rashid and Sawyer 2000b; Rashid, Saw- 
yer, et al. 2000; Rashid 200 Id; Rashid 2001c; Rashid 2001a; Rashid and Saw- 
yer 2001), AspOEv (Green and Rashid 2002; Rashid 2003) and GOODS 
(Knizhnik 2003). 



4.2.1 Instance Adaptation Approach 

In Sect. 3.1.1 the crosscutting nature of instance adaptation code at the 
DBMS level was highlighted. In the following subsections, we look at two 
object database evolution systems, SADES and AspOEv, which employ AOP 
techniques to modularise instance adaptation behaviour at the DBMS level 
hence, supporting customisability of such behaviour with localised changes. 

4.2.1 .1 Customisable Instance Adaptation in SADES 

Before discussing the aspectisation of the instance adaptation approach in 
SADES, it is important to understand the evolution model employed by the 
system. This is because the join points in the instance adaptation aspects are 
based on the versioning semantics in SADES. 

The SADES evolution model (Rashid and Sawyer 1998; Rashid 2000a) is 
based on superimposing schema modification on class versioning offering 
a composite evolution approach providing support for: 

• class hierarchy evolution; 

• class versioning; 

• object versioning. 

The evolution model employs version derivation graphs (Loomis 1992). 
The conceptual schema in the model is a fully connected directed acyclic 
graph (DAG) depicting the class hierarchy in the system (note that the 
model allows multiple inheritance). Each node in the DAG is a class version 
derivation graph (CVDG). Inheritance relationships in the model, there- 
fore, exist at two levels: 




The DAG level; 
The CVDG level. 
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Consider, for example, Fig. 4.2 which presents an example graph struc- 
ture showing the class hierarchy. Two nodes of the DAG are shown along 
with their associated CVDGs. The dashed arrows (with solid arrowheads) 
inside each node represent the derivation path for the class versions. The 
solid line arrows (with hollow arrowheads) show the conceptual (DAG 
level) inheritance relationship between the two classes while the dashed line 
arrows (with hollow arrowheads) represent the actual (CVDG level) inher- 
itance relationships between various versions of these classes. 

Version B1 oi class B has as its superclass version A3 of class A while both 
versions B2 and B3 inherit from the version A2. Conceptually, the subclass 
can only inherit from the superclass (assuming that the class has only one 
superclass) but each version of the subclass might be inheriting from a sep- 
arate version of the superclass. It is also possible that version B2 of class B 
in Fig. 4.2 might be the result of changing its superclass to be version A2 and 
not A3. References to subclasses need to be maintained to make sure that 
correct subclass instances are substituted for the class under consideration. 
For example, from Fig. 4.2, only an instance of the subclass version B1 can 
be substituted where an instance of class version A3 is required. The 
instance adaptation approach (described later in this section) supports 
direct instance sharing (Ra and Rundensteiner 1997) between the various 
class versions and adapting instances from one class version to another. 

Each node of a CVDG keeps a set of references to a set of object version 
derivation graphs (OVDG). An OVDG is similar to a CVDG but keeps 
information about various versions of an instance rather than a class. Since 
an OVDG is generated for each instance associated with a class version, a 
set of OVDGs results when a class version has more than one instance asso- 
ciated with it. As a result a CVDG node keeps a set of references to all these 
OVDGs. 
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Fig. 4.2. A simple class hierarchy in SADES with superclass subclass links between 
various nodes of the CVDGs 

Fig. 4.3 shows the modularisation of the instance adaptation approach in 
SADES. The instance adaptation approach is separated from the schema 
manager and encapsulated in an aspect. The instance adaptation aspects are 
specified using a declarative aspect language. The choice of a declarative 
aspect language, in this instance, has been dictated by the need to specify 
instance adaptation aspects (and any customisations to them) at the appli- 
cation programming level. This makes it possible for the application pro- 
grammer to customise the instance adaptation mechanism to the specific 
needs of an organisation or application with minimal effort. 
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Fig. 4.3. Use of aspects for customisable instance adaptation in SADES 
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The SADES aspect language has been modelled on an earlier version of 
Aspect! (0.4) ^ It provides three simple constructs facilitating: 

• specification of join points between the aspects and class versions: the 
crosscut construct which takes the form crosscut <classname>: 
<cl ass versi on name>; 

• introduction of new methods into the class versions: the introduce con- 
struct which takes the form introduce <method returntype> <meth- 
odnameXmethod arguments)) {<method body)}; 

• redefinition of existing methods in the class versions: the redefine con- 
struct which takes the form redefine <method return type) <meth- 
odname)( method arguments)) {<new method body)}. 

The main join point of interest in the instance adaptation aspect is as fol- 
lows: 

crosscut SADESRoot:Root( 

redefine SADESSurrogObj Ver i nvokeAdapta ti oRouti ne 
(String propertyName , 

SADESSurrogObj Ver theValue, 

Integer readWrite) 

Kcode for the instance adaptation approach to be used}) 

SADES is a single-rooted system, i.e., all classes and meta-classes inherit 
from the system class SADESRoot (cf. Sect. 4.3.1). SADES is also a self 
descriptive system. Therefore, SADESRoot follows the same versioning 
semantics (described in the evolution model) as for the other classes in the 
system. It has only one root version. The join point above simply redefines 
the i nvokeAdapta ti onRouti ne method in the Root class version for the 
SADESRoot class. In the current implementation of SADES this method is 
provided as a hook in SADESRoot : Root. However, it could easily be intro- 
duced by the instance adaptation aspect using the introduction feature in 
the aspect language. 

Instances of all classes in SADES map on to objects of the type SADES- 
SurrogObjVer in the underlying lasmine database (SADES has been 
implemented as a layer on top of Jasmine (Jasmine 1996)). The invokeAd- 
aptati onRouti ne method always returns an adapted instance (by invok- 



1. The SADES aspect language was developed when AspectJO.4 was the latest version of 
Aspect! and the functionality offered by these features has remained sufficient for the 
needs of SADES. As a result, the SADES aspect language has not been evolved in sync 
with Aspect!. 




60 4. Applying AOP in Database Systems 



ing the appropriate instance adaptation routine (cf. Sect. 4.3.3)) of type 
SADESSurrogObjVer. The propertyName argument provides the name of 
the object attribute accessed by the application while the readWrite argu- 
ment reflects the nature of the access, i.e., a read operation or a write opera- 
tion. In case of a write operation the theVal ue argument provides the 
value being written to the attribute specified by propertyName. 

As shown by the shaded boxes in Fig. 4.3, the instance adaptation 
approach can be customised or completely exchanged with changes loca- 
lised to the aspect. Only the i nvokeAdaptati onRouti ne method needs to 
be redefined. This use of aspects has made it possible to successfully imple- 
ment two different instance adaptation approaches in SADES namely, the 
error handlers approach (which simulates object conversion) from 
ENCORE (Skarra and Zdonik 1986) and the update/backdate methods 
approach (which physically converts objects across class versions) from 
CLOSQL (Monk and Sommerville 1993). Note that in SADES the custom- 
isation or exchange of the instance adaptation approach may be carried out 
statically or dynamically as the instance adaptation aspect can be woven (or 
rewoven) into the schema manager at both compile-time and run-time (as 
shown by the dotted arrow). Readers are referred to Sect. 5.3.2 for further 
details of the SADES aspect weaver. 

4.2.1 .2 Customisable Instance Adaptation in AspOEv 

The AspOEv framework employs aspects to support customisation of both 
the instance adaptation approach and the evolution model of an object-ori- 
ented database system. The use of aspects to support customisation of the 
evolution model in AspOEv is discussed in Sect. 4.2.2. In this section we dis- 
cuss how the framework aspectises the instance adaptation approach. 

The framework employs its own language, Vejal, with a versioned type 
system to support instance adaptation across schema changes. A combina- 
tion of aspects and hot spots, as in object-oriented frameworks (Fayad and 
Schmidt 1997), is used to support customisation. The framework has been 
implemented as an integral part of an interpreter for Vejal. Applications are 
written in Vejal, whereas the framework and its concrete instantiations are 
implemented in Aspect] 1.06 and Java. The current implementation of the 
framework is based on the underlying ODBMS exposing an ODMG Java 
binding (Cattell, Barry, et al. 2000). However, customisable evolution for a 
range of database systems, including object-relational systems, can be sup- 
ported by porting the implementation to the Java Data Objects ( JDO) stan- 
dard (Roos 2002). 
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AspOEv supports plugging in different approaches to instance adapta- 
tion. As shown in Fig. 4.4, the hot spots are exposed using the abstract class 
Adapter in a white-box fashion^. In order to customise the instance adap- 
tation approach subclasses of Adapter have to concretise two abstract 
methods: 

• public abstract SysObj createObj(ClassRef classRef, Env env) 

This method is overridden to create the new object in case of physical 
conversion or circumvent the creation in case of simulated conversion. 
SysObj is the object to be created upon adaptation; cl assRef refers to 
the class the object is to be an instance of; en v is the current environment 
of the running thread in the Vejal interpreter. 

• public abstract SysObj convert (SysObj old, ConversionE conv, Env env) 
This method is called by the underlying Vejal converter (conv) which 
invokes the instance adaptation aspects. It encapsulates the main logic 
for the particular instance adaptation approach offered by the concrete 
subclass of Adapter. 

The three customisations currently implemented using the framework 
include (cf. Fig. 4.4): 

• View Adapter (non-materialised views): a simulated conversion 
approach, which recalculates the view for each read operation rather 
than storing it. An exception is the case of entirely new fields, which have 
to be stored as hidden fields in the original object. 

• Converter Adapter (physical conversion): converts the object in-place 
and physically changes its class. 

• Elastic Converter Adapter (elastic conversion): a variation of the basic 
physical conversion approach hence implemented as an aspect inherit- 
ing from Converter Adapter (aspects in Aspect! can inherit from classes 
but not vice versa). The aspect does not override any functionality in its 
superclass. Therefore, the object is physically converted. However, an 
advice in the aspect traps the join point when the converted object is 



2. White-box frameworks employ inheritance to configure the hot spots hence requir- 
ing that the architecture of the framework is known to the application developers 
who build upon it. 
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about to be written to disk at the end of the transaction (black-box cus- 
tomisation^) and reverts it to its previous schema version. 




Fig. 4.4. UML diagram of classes and aspects for customisation of instance adaptation 
in AspOEv 

The customisations are beneficial because non-materialised views might 
be more appropriate in situations requiring reduction in memory con- 
sumption, while physical or elastic conversion might be more suitable in 
others because of its caching behaviour. Note that although some of the 
instance adaptation approaches are implemented as classes, they still 
encapsulate a crosscutting concern (and hence, serve as aspects) with the 
AspOEv framework providing means for the composition of the concerns 
encapsulated by these classes with other evolution concerns. This further 
reflects the fact that the term aspect does not imply a particular representa- 
tion and conventional separation of concerns mechanisms such as classes 
can be used to separate crosscutting concerns provided appropriate com- 
position support is made available. 

Other instance adaptation customisations are possible in AspOEv and, at 
least for all the approaches so far considered in the framework, do not 
require any changes whatsoever to the instance adaptation aspects at the 
database level. This is because instance adaptation aspects at the database 
level (cf. Sect. 4.3.3. 2) are written in a field- view- oriented style, i.e., speci- 
fying how to obtain any given field of the destination object. This means 



3. Black-box implementations hide the internal structure of the framework by employ- 
ing composition as the customisation mechanism hence, requiring knowledge of the 
hot spots only and not the internal structure of the framework. 
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that they can be used as-is in non-materialised views, or in other 
approaches the list of fields in a class can be iterated through and all fields 
pulled through the instance adaptation aspect like a sieve. This is essentially 
a special case of separating core code from caching concerns. 



4.2.2 Schema Evolution Model 

The composite evolution model offered by SADES (cf. Sect. 4.2. 1.1), 
though rich and powerful (Rashid 2002a), is not customisable. The AspOEv 
framework, in contrast, supports adoption of different evolution models in 
line with the specific needs of an organisation or application. Similar to cus- 
tomisation of instance adaptation, it exposes hot spots for customising the 
schema evolution approach in a white-box fashion (cf. Fig. 4.5). However, 
instead of using a class hierarchy, an aspect hierarchy is employed. Advices 
in the aspects support the customisation by operating on other parts of the 
framework, mainly those pertaining to resolution of object references upon 
retrieval from the database (black-box customisation). The two abstract 
aspects. Vers 1 on 1 ng Mode and Abstract N-Version Mode expose a range 
of abstract methods that are concretised by the sub-aspects to customise the 
schema evolution approach. 

Currently three versioning modes for schema evolution are supported 
(cf. Fig. 4.5): 

• N-Version Mode: unrestricted schema evolution is allowed. Instead of 
duplicating every single class on disk each time a schema is updated, only 
the classes that have changed are allocated new version numbers. This 
means that references to classes have to be indirect (versionless) on disk, 
because Person could refer to Person[l] orPerson[2] depending on 
the schema version in use by an application. 

• One Version Mode: only one schema version exists in the database. This 
provides some optimisations in case of applications where change histo- 
ries are undesirable. All on-disk references to classes now refer directly to 
resolved classes, rather than indirect references as in N- version mode. 

• N-to-1 Transition Mode: to go from N- version mode to one version 
mode. This is essential as a significant amount of disk activity is required 
to get the database into one version mode. Note that there is no transi- 
tion period to go from one version mode to N-version mode. The tran- 
sition is virtually instantaneous. 
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Fig. 4.5. UML diagram of aspects for customisation of schema evolution approach 



4.2.3 Transaction Model 

The Generic Object-Oriented Database System (GOODS) (Knizhnik 2003) 
supports application-specific customisation of the transaction model and 
related concerns such as locking and caching. It employs a meta-object"^ 
protocol for the purpose. All classes whose instances can be stored in the 
database extend the GOODS system class Persistent, hence inheriting an 
instance-level variable of type MetaObject. The meta-object pointed to by 
this instance variable has its preDaemon() and postDaemon() methods 
(cf. shaded part in Fig. 4.6a) invoked for each method invocation or 
attribute access for the associated persistent object. The preDaemon ( ) and 
postDaemon ( ) methods serve the same purpose as before and after 
advices in aspect languages such as Aspect} (though they cannot be attached 
to advanced join points such as control flow). 

The GOODS meta-object protocol automatically identifies methods that 
might mutate or modify a persistent object. The two static methods in the 
MetaObject class (shown in Fig. 4.6a) can be invoked by any application 
code to explicitly indicate that a method is a mutator or modifies the state 



4. Note that the term meta-object is used here in the sense of reflection and not to 
denote schema elements. 
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of the object. The remaining abstract methods are concretised by the sub- 
classes to implement a specific transaction model and related concerns 
namely, locking and caching. 



MetaObject 



beginReadA ccess (goods] pi. Persistent obj) 
begin WriteAccess(goodsjpi. Persistent obj) 
commitObjectChangesjgoodsjpi.Persistent obj) 
destroyObject(goodsjpi. Persistent obj) 
endA ccess (goodsjpi. Persistent obj) 
forgetObjectjgoodsjpi. Persistent obj) 
invalidateObjectjgoodsjpi.Persistent obj) 
loadObjectjgoodsjpi.Persistent obj) 

makePersistentjgoodsjpi.Persistent obj, goodsjpi.Persistent parent) 
notifyOnModificationjgoodsjpi.Persistent obj, boolean status) 
preloadObjectjgoodsjpi.Persistent obj, int size) 
releaseObjectjgoodsjpi. Persistent obj) 
undoObjectChanges (goodsjpi.Persistent obj) 
preDaemon(java.lang.Objevt obj. ini attr^ 
postDaemon(java.kmg.Ohjeci obj, int aitr boolean modified) 
«static» mutator( ) 

«static» modify ( ) 



Fig. 4.6a. Abstract MetaObject class in GOODS exposing customisation points for 
transaction processing concerns 

As shown in Fig. 4.6b, in the current GOODS implementation (version 
2.67), the transaction model (supporting nested transactions) and caching 
behaviour is implemented in an abstract subclass BasicMetaObject. This 
class concretises most of the abstract methods in the M e t a 0 b j e c t class. The 
concretisation of the following three methods is left to concrete subclasses 
of Basi cMetaObject: 

• begi nReadAccess ( ) 

• begi nWri teAccess ( ) 

• endAccess ( ) 
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Fig. 4.6b. The meta-object hierarchy in GOODS 



The concrete methods in the subclasses (cf. Fig. 4.6b) are used to imple- 
ment different locking schemes that can be employed by the applications. 
Currently, three locking schemes have been implemented and can co-exist 
within the context of an application (some objects can be locked using one 
scheme and others using a different scheme if desired). The locking 
schemes currently supported in GOODS are: 

• Optimisitc locking: allows multiple readers and multiple writers. When a 
transaction that modifies an object attempts to commit, the server 
checks if the client has the most recent version of the object. If so, the 
transaction is committed otherwise it is aborted. The optimistic locking 
scheme is suitable for situations where conflicts are rare and objects 
accessed in the read-only mode do not necessarily need to be up-to-date. 

• Pessimistic locking: supports acquiring an exclusive lock when an object 
is being modified. Objects accessed in read-only mode are not locked. 
The scheme is useful in situations where it is essential that no updates are 
lost but read-only transactions do not require the most up-to-date cop- 
ies of the objects. 

• Pessimistic, repeatable read locking: supports shared locks in read-only 
mode and exclusive locks when an object is being modified by a transac- 
tion. This scheme offers the highest level of consistency at the expense of 
performance due to additional locking overhead. 

GOODS currently offers only one transaction model. However, other 
models can be implemented as subclasses of MetaObject. Note that 
although GOODS supports customisability, it does not untangle the trans- 
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action model from locking and cache management concerns. Any new 
transaction model will also have to implement cache management (cur- 
rently implemented as part of the BasicMetaObject functionality). It will 
also need to provide locking mechanisms or duplicate this functionality 
already implemented in subclasses ofBasicMetaObject. Such customisa- 
tions could be improved by using a mechanism similar to that supported by 
Aspect} where classes can be made to implement a particular interface with 
concrete behaviour attached to the methods defined in the interface. 



4.3 AOP at Database Level 

This section discusses existing systems employing AOP to modularise 
crosscutting concerns at the database level. We will first discuss the aspec- 
tisation of links among persistent entities and versioning in SADES. This 
will be followed by a discussion of aspectising the instance adaptation rou- 
tines in SADES and AspOEv. 



4.3.1 Links among Persistent Entities 

Before discussing the separation of links among persistent entities in 
SADES using semantic relationships and composition filters, it is important 
to look at the SADES architecture. This is because relationships play an 
important role in the flexibility and extensibility of the system. 

4.3.1 .3 Overview of SADES Architecture 

The separation of concerns principle has been employed during all the 
stages of development of SADES. Therefore, it also forms the basis of the 
system architecture. As show in Fig. 4.7, the architecture is based on divid- 
ing the database system into a set of spaces each hosting entities of a partic- 
ular type. Three basic types of entities and their encapsulating spaces are 
shown: 

• Objects: reside in the object space and are instances of classes. 

• Meta-objects: Classes, class properties, class methods, etc. form the 
meta-object space. 

• Meta-classes: constitute the meta-class space and are used to instantiate 
meta-objects. 
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Note that Fig. 4.7 shows only three basic types of entities residing in an 
object database. Later, while discussing the instance adaptation approach in 
SADES (cf. Sect. 4.3.3. 1), it will be demonstrated how the above architec- 
ture makes it possible to extend the database with new types of entities (and 
their encapsulating spaces) with minimal effort. 

The links between entities residing in different spaces are maintained 
through interspace relationships. Fig. 4.7 shows the bi-directional instantia- 
tion inter-space relationships between meta-classes and meta-objects, and 
meta-objects and objects. Intraspace relationships can exist among entities 
residing within the same space. In the meta-object space, for example, these 
can be the derives-from/inherited-by inheritance relationships among class 
meta-objects or the defines/ deftned-in aggregation relationships among 
class meta-objects and attribute and method definition meta-objects. In the 
object space these can be association and aggregation relationships among 
the various objects residing in that space. 
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Fig. 4.7. Spaces, inter-space and intra-space relationships in SADES 
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As shown in Fig. 4.7, the notion of spaces and inter-space and intra-space 
relationships has been derived directly from the viewpoints of the various 
developer/user roles in the database environment: 

• The DBMS designer is interested in providing a suitable set of meta- 
classes that can be instantiated by the database designer/maintainer to 
create the database schema. S/he is also interested in providing means for 
introducing new meta-classes so that the system can be extended with 
new types of entities if required. The new meta-classes might bear some 
relationships with existing meta-classes. The meta-class space and the 
notion of intra-space relationships in the meta-class space have been 
derived from these DBMS designer viewpoints. 

• The inter-space relationships between the meta-class space and the 
meta-object space have been derived from two overlapping viewpoints: 
that of the DBMS designer and that of the database designer/maintainer. 
The DBMS designer is interested in providing effective instantiation 
mechanisms for the meta-classes while the database designer/maintainer 
is interested in using these mechanisms to create the meta-objects form- 
ing the database schema. 

• The database designer/maintainer is also interested in creating appropri- 
ate meta-objects forming the database schema which can then be instan- 
tiated by the application developer/end user to store application data in 
the database. S/he is also interested in modifying the relationships 
among meta-objects (e.g., derives-from/inherited-by relationships among 
class meta-objects or defines/ deftned-in relationships among class meta- 
objects and attribute and method definition meta- objects), introducing 
new relationships among meta-objects or removing existing ones in 
order to evolve the schema of the database in line with changes in appli- 
cation requirements. The meta-object space and the notion of intra- 
space relationships in this space have been derived from these database 
designer/maintainer viewpoints. 

• The overlapping viewpoints of the database designer/maintainer and the 
application developer/end user roles form the basis of the inter-space 
relationships between the meta-object space and the object space. The 
database designer/maintainer is interested in exposing appropriate 
instantiation mechanisms for the meta-objects while the application 
developer/end user is interested in using these mechanisms to instantiate 
the meta-objects and populate the database. 
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• The application developer/end user is also interested in manipulating the 
objects in the database and any association or aggregation links among 
them. These viewpoints have been used to derive the notion of an object 
space and its intra-space relationships. 

The viewpoint based division of the database into spaces and identifica- 
tion of the various inter-space and intra-space relationships makes it possi- 
ble to address the requirements of the various roles in an incremental fash- 
ion. In SADES this has provided a clearer mapping from the extensibility 
and customisability requirements of the various roles to the system archi- 
tecture making it possible to extend the system with new types of entities 
(introduction of new meta-classes), spaces, inter-space and intra-space 
relationships and customising existing spaces by manipulating their inter- 
space and intra-space relationships with minimal knock-on effect on enti- 
ties already residing in the existing spaces. 

4.3.1 .2 Separation of Links using Composition Filters 

In the SADES architecture (cf. Fig. 4.7) the links among entities, whether 
they reside in the same space or different spaces, are represented by rela- 
tionships. Relationships are semantic constructs which are natural to 
manipulate for maintainers and developers of object-oriented systems. 
Therefore, relationships in the SADES architecture have been directly 
mapped onto implementation. The links among entities are implemented 
as relationship constructs which are first class objects and encapsulate 
information about connections among the entities. This results in connec- 
tion information being separated from the entities localising changes to 
these connections. This is in direct contrast with existing object database 
evolution systems, which embed connection information within the enti- 
ties (cf. Sect. 3.2.1) hence spreading the relationships across them. 

In the SADES meta-model (visible to an experienced application devel- 
oper or a database administrator and not to the novice developer) relation- 
ships are treated in a uniform fashion regardless of whether they are inter- 
space or intra-space relationships. Intra-space relationships are treated in 
the same manner whether they exist within the object space, the meta- 
object space or the meta-class space. No distinction is made between inter- 
space relationships, i.e., relationships among meta-objects and objects are 
treated the same way as those that exist between meta-classes and meta- 
objects. 
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In order to treat relationships in a uniform manner, all classes and meta- 
classes in the system inherit from the class Root which is shown in Fig. 4.8a. 
As shown in Fig. 4.8b, the class has replicas existing in both the meta-class 
space and the meta-object space. The meta-classes inherit from the meta- 
class Root (referred to as SADESRoot in Sect. 4.2.1. 1) which exists in the 
meta-class space while the classes (which are meta-objects) inherit from the 
meta-object Root which resides in the meta-object space and is an instance 
of the meta-class Class. Inheriting from the Root replica in the meta-class 
space allows dynamic introduction, removal and modification of relation- 
ships in which meta-objects participate while inheriting from the Root rep- 
lica in the meta-object space allows dynamic introduction, removal and 
modification of relationships in which the various objects participate. 



Root 



class: 

createNewRelationship(String name. 

Char edgeCardinality, 

Root class/meta-class inverse. 
String inverseName, 

Char inverseEdgeCardinality 

) 

deleteExistingRelationship(String name) 



Fig. 4.8a. The class Root from which all classes and meta-classes inherit 
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Let us now discuss how the class Root allows dynamic introduction, 
removal and modification of relationship definitions. Note that the class: 
tag in Fig. 4.8a indicates class-level (static) properties and methods while 
the tag class/meta-class indicates that the value of the parameter has to 
be a class (which is a meta-object) or a meta-class. Inheriting from the class 
Root allows the particular class or meta-class to use the class-level (static) 
methods createNewRel ati onshi p and del eteExi sti ngRel ati on - 
ship. These methods allow the dynamic addition or deletion of relation- 
ships in which instances of the class or meta- class participate. It should be 
noted that the inverse traversal path is implicitly created when createNe- 
wRel ati onshi p is invoked. Uni-directional relationships can be created 
by specifying a null value for the last three parameters ofcreateNewRela- 
ti onshi p. Recursive relationships can be set up by specifying the same 
class or meta- class on which the method is being invoked as an inverse. The 
inverse traversal path is implicitly deleted when deleteExistingRela- 
t i 0 n s h i p is invoked on one of the classes or meta-classes whose instances 
participate in the relationship. 
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For each relationship, which the instances of a class or meta-class parti- 
cipate in, aRelationship Structure instance is created. These instances 
are used to store and dynamically modify the structure of the relationship. 
The class Relationship Structureis shown in Fig. 4.9a. The instance: 
tag in Fig. 4.9a indicates instance-level properties and methods. Note that 
the Relationship Structure class does not inherit from the class Root. 
The instance-level methods setName, setInverseRel ati onshi p and 
setEdgeCardinality can be invoked on instances of the class in order to 
dynamically modify the structures of relationships whose details they store. 

A composition filters mechanism (a custom implementation for 
SADES) is employed to ensure that any messages manipulating the rela- 
tionship definitions are received by the Rel ati onshi p Structure objects 
and not by the class or meta-class objects (for whose instances these rela- 
tionships are defined). As mentioned earlier, composition filters are ideal 
candidates for situations requiring message interception. In SADES they 
are implemented as first class objects attached and detached using API calls 
hence, not requiring any extensions to the basic system architecture shown 
in Fig. 4.7. The method invocation mechanism in SADES has been adapted 
to keep track of entities with attached filters. It ensures that all messages to 
and from an entity get routed through its attached input and output filters 
respectively. As shown in Fig. 4.9b, a dispatch filter intercepts all incoming 
relationship definition manipulation messages and delegates them to the 
Rel ati onshi p Structure objects. 



Relationship Structure 



instance: 

String name 

Root class/meta-class className 
Relationship Structure inverse 
Char edgeCardinality 



instance: 

getName( ) 
getClass( ) 

getInverseRelationship( ) 
getEdgeCardinality( ) 

getCardinality( ) 

setName(String newName) 

setInverseRelationship(Relationship Structure newinverse) 
setEdgeCardinality(Char newEdgeCardinality) 



Fig. 4.9a. The Rel ati onshi p Structure class 
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Incoming Relationship 
Definition Manipulation 
Messages I 




Fig. 4.9b. Implementation of relationship definitions in SADES using Rel ati onsh1 p 
Structure objects and composition filters 



Fig. 4.10a shows the relationship classes in the SADES meta-model The 
class Relationship is an abstract class. Relationships are created as 
instances of classes Rel ati onshi p_l and Rel ati onshi p_n. These 
instances act as edges of the relationship; an instance of class Rel ati on - 
ship_l represents an edge cardinality of one while an instance of class 
Re 1 a t i 0 n s h i p_n represents an edge cardinality of many. Ordering seman- 
tics for relationships can be provided by using an ordered collection, such 
as a list or an array, for participants. Note that only the instances of 
classes or meta-classes that inherit from the class Root can participate in a 
relationship. Also note that the relationship classes in Fig. 4.10a do not 
inherit from the class Root. 

The Re 1 a t i 0 n s h i p_l and Re 1 a t i o n s h i p_n instances for entities par- 
ticipating in a particular relationship are encapsulated in a Relationship 
Participants object. In a fashion similar to manipulation of relationship 
definitions, a composition filters mechanism is employed to ensure that any 
messages manipulating links among entities are received by the Relation- 
ship Participants objects and not by the entities connected by their 
Rel ati onshi p_l and Rel ati onshi p_n components. As shown in Fig. 
4.10b, a dispatch filter intercepts all incoming relationship manipulation 
messages and delegates them to the Re 1 a t i o n s h i p Participants object. 

Since the relationship information in SADES is no longer embedded 
within the participating entities it can be modified in an independent fash- 
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ion. It is also possible to introduce new relationships or remove existing 
ones with localised changes. This results in cost-effective schema modifica- 
tions (changes to intra-space relationships in the meta-object space). It also 
improves the extensibility of the system as introduction of new meta-classes 
only requires introduction of new relationship objects. 




Fig. 4.10 a. The Relationship Model 



Incoming Relationship 
Manipulation Messages 




Dispatch Filters C) 

participalirig in the relationship 



Fig. 4.10b. Implementation of links among entities using Relationship Partici- 
pants objects and composition filters 






76 4. Applying AOP in Database Systems 



Fig. 4.1 1 shows the various meta-classes in SADES and the relationships 
in which their instances, the meta-objects, participate. Note that all meta- 
classes inherit from the class Root. A special stereotype <<1 instance of 
subclass of Root>> indicates that the relationship exists among 
instance(s) of the particular meta-class and instance(s) of a sub-class of the 
class Root. An instance of the class OVDG Node, for example, manages an 
object which is an instance of a sub-class of the class Root (since all classes 
inherit from the class Root). Similarly, a class Property or a method 
Parameter will normally have a sub-class of the class Root as its type. 




Fig. 4.11. UML diagram of meta-classes in SADES and the relationships their instances 
participate in (using the composition filters implementation) 



4.3.1 .3 Change Propagation and Referential Integrity 

Closely related and overlapping with the notion of links or relationships 
among entities are the concepts of change propagation and referential integ- 
rity. Referential integrity means that all entities must always refer to other 
existing entities. This implies that relationship objects in SADES must 
always connect entities that exist in the system. If an entity is removed (e.g., 
a class meta- object during schema evolution) the relationship object should 
be made aware of this change and must not refer to that entity as a partici- 
pant in the relationship. Similarly, if an entity no longer participates in a 
relationship its associated dispatch filter must not attempt to delegate mes- 
sages to the relationship object. 

Change propagation means that any changes to a particular type of rela- 
tionship or its participating entities should be propagated to the other parts 
of the system (e.g., other participating entities) in line with the propagation 
semantics defined for that type of relationship. A number of different types 
of relationships with different propagation semantics exist in SADES. 
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Inheritance relationships, for example, require that changes to the structure 
of a class be propagated to its sub-classes. Similarly, aggregation relation- 
ship require that operations be propagated from aggregate to part, with 
deletion of the aggregate resulting in deletion of the parts, but not vice 
versa. Note that these propagation semantics cannot be fixed as some appli- 
cations might require changes to them. (Zhang, Haerder, et al. 1997), for 
example, identify a number of different propagation semantics for aggrega- 
tion relationships. Hence, it must be possible to modify change propaga- 
tion behaviour with localised changes. 

The change propagation and referential integrity behaviour refers to 
both relationship objects and entities connected by them. It, however, 
requires very little information about the structure of individual relation- 
ship objects or entities. Instead, it requires more generic information such 
as the type of relationship or the type of evolution operation performed on 
an entity. In Chap. 2 it was pointed out that adaptive programming is 
highly suitable for separating behaviour from structure. As shown in Fig. 
4.12a, it has, therefore, been employed (also a custom implementation for 
SADES) to implement change propagation and referential integrity in 
SADES. A traversal strategy specifies the various operations on relation- 
ships and entities requiring referential integrity enforcement. The referen- 
tial integrity behaviour is described on the basis of this traversal strategy. 
Similarly, a set of traversal strategies specifies different propagation seman- 
tics for different types of relationships in the system. The change propaga- 
tion behaviour is specified on the basis of these traversal strategies. In 
SADES traversal strategies are implemented as directed graphs with each 
node in the graph representing a traversal node in the traversal strategy. 
Similar to the composition filters implementation this does not require any 
extensions to the basic system architecture shown in Eig. 4.7. Eig. 4.13a 
shows a traversal strategy (in pseudo code) for operation propagation in 
aggregation relationships in SADES. It represents the propagation of oper- 
ations from aggregate to parts as mentioned earlier. Eig. 4.13b shows the 
traversal graph dynamically generated when an operation needs to be prop- 
agated. The black node represents the aggregate where an operation is ini- 
tially performed while the first-level gray nodes represent parts of the aggre- 
gate to which the operation is propagated. Note that the propagation 
strategy in Fig. 4.13a defines recursive propagation. Therefore (as shown in 
Fig. 4.13b), the operation is propagated to the nodes to which the first-level 
nodes might be an aggregate. 
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Fig. 4.12. (a) Using hybrid AOP to implement links, change propagation and referential 
integrity (b) Implementation of change propagation and referential integrity using 
adaptive programming 



Fig. 4.12b shows that the change propagation behaviour is built on top 
of the system layer implementing referential integrity. This is because 
change propagation often triggers the need to ensure referential integrity, 
e.g., dropping of a class meta-object forming a non-leaf node in the data- 
base schema requires that this change be propagated to the sub -classes in 
line with the propagation semantics for inheritance relationships. However, 
this also requires that the relationship object for the inheritance relation- 
ship no longer refers to the removed meta-object as a participant. 



theNode := container node 
while theNode is a container 
if exist contained nodes 

propagate operation to contained node 

(a) 

Fig. 4.13. (a) Traversal strategy for operation (change) propagation in aggregation rela- 
tionships (b) Run-time traversal graph for the traversal strategy in (a) 




4.3.2 Versioning 

As mentioned earlier SADES employs class versioning to evolve the struc- 
ture of classes in the object database schema. In addition to this support for 
class versioning SADES also provides support for keeping track of changes 
to the objects in the object space through object versioning. In SADES ver- 
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sioning support for entities is customisable. This is because versioning 
requirements can vary from one application (or organisation) to another. 
Mostly the workgroup support features (e.g., checking data in and out of the 
shared database to private or group workspaces) (Katz 1990) are strongly 
dependent on the individual work practices of each organisation. Some 
applications might want to bind objects into configurations (Katz 1990) and 
use these configurations as units of versioning. Some applications might 
only require support for linear versioning (Loomis 1992) (where a version is 
derived from only one existing version) while others might require support 
for branch versioning (Loomis 1992) (where a version may be derived from 
multiple existing versions). Therefore, it is essential to separate versioning 
behaviour from the versioned entities in order to localise changes during 
customisation of the versioning approach. 

As mentioned earlier, adaptive programming is highly effective in sepa- 
rating behaviour from structure and hence, has been employed to separate 
versioning behaviour from the versioned entities. As shown in Fig. 4.14, 
traversal strategies for this separation are specified as version derivation 
graphs (Loomis 1992). A general versioning graph exists for any versioned 
entity. Each node in the general versioning graph has the structure shown 
in Fig. 4.15a. Special refinements of the general versioning graph can be 
defined for specific types of entities (e.g., for classes and objects as shown in 
Fig. 4.14). The structures of nodes in class version derivation graphs and 
object version derivation graphs are shown in Fig. 4.15b and 4.15c respec- 
tively. The versioning behaviour involving any workgroup support fea- 
tures, special semantics for versions, support for linear or branch version- 
ing, etc. is written against the general structure of the various version 
derivation graphs. 
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Fig. 4.14. Traversal strategies based on version derivation graphs 



• Reference(s) to predecessor(s) 

• Reference(s) to successor(s) 

• Reference to the versioned entity 

• Descriptive information about the 
version such as creation time, creator’s 
identification, etc. 



(a) 



Reference(s) to predecessor(s) 
Reference(s) to successor(s) 

Reference to the versioned class meta- 
object 

Descriptive information about the class 
version such as creation time, creator’s 
identification, etc. 

Reference(s) to super-class(es) 
version(s) 

Reference(s) to sub-class(es) version(s) 
A set of references to objects 
instantiated using the class version 
definition 

(b) 



Reference(s) to predecessor(s) 
Reference(s) to successor(s) 
Reference to the versioned object 
Descriptive information about the 
object version such as creation time, 
creator’s identification, etc. 



(c) 



Fig.4.15a-c. Structure of versioning graph nodes (a) general version derivation graph 
nodes (b) version derivation graph nodes refined for class versioning (c) version deriva- 
tion graph nodes refined for object versioning 



Fig. 4.16 shows that the versioning functionality has been implemented 
(using hybrid AOP) in a system layer which exploits the separation of con- 
cerns in the system layer implementing links among entities, change prop- 
agation and referential integrity. The predecessor/successor links among the 
nodes of version derivation graphs are implemented using relationship 
objects. New propagation semantics are defined for the predecessor /succes- 
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sor relationships to ensure change propagation and referential integrity 
when these relationships are modified by introduction of new versions or 
removal of existing ones. 




Fig. 4.16. Hybrid aspect-oriented implementation of versioning as a layer on top of the 
aspectisation of links, change propagation and referential integrity 



4.3.3 Instance Adaptation Routines 

In Sect. 4.2.1, the aspectisation of the instance adaptation approach at the 
DBMS level in SADES and AspOEv was discussed. This section discusses 
how aspects have been employed to modularise the instance adaptation 
routines at the database level in the two systems. 

4.3.3.4 Instance Adaptation Routines in SADES 

In SADES, any instance adaptation routines are specified by the database 
maintainer at the application programming level. Therefore, the declarative 
aspect language used to specify the aspects encapsulating the instance adap- 
tation approach (cf. Sect. 4.2.1) is also employed to specify the instance 
adaptation routines separately from the class version definitions (cf Fig. 
4.17a). The aspect specification provided by the aspect language is parsed 
to generate the aspects and associate these with the class versions using rela- 
tionship objects. 

Since the generated aspects are persistent in nature - they relate to the 
class version definitions in the database schema - there arises a need to sup- 
port these new persistent abstractions in the database. The extensible archi- 
tecture of SADES, described in Sect. 4.3. 1.1, has made it possible to extend 
the system with the notion of an aspect space in a seamless fashion. 
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Fig. 4.17. Instance adaptation in SADES at the database level (a) Separating instance 
adaptation routines from class versions using aspects (b) Invocation process for instance 
adaptation routines 




Fig. 4.18. Extension of SADES with an aspect space 
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As shown in Fig. 4.18, aspects reside in the aspect space and are instances 
of the meta-class Aspect. For simplicity only one aspect has been shown. 
Also note that the concept of inter-space and intra-space relationships (and 
their implementation through relationship objects and composition filters) 
seamlessly extends to the aspect space. Aspects in the aspect space bear 
aspect-of/has-aspect relationships with entities residing in other virtual 
spaces. Although not shown in Fig. 4.18, intra-space relationships can exist 
within an aspect space. 

Fig. 4.17b depicts the case when an application attempts to access an 
object associated with version 1 of class A using a different interface (this 
may be the version set interface or the interface of another version of the 
same class). The aspect containing the instance adaptation routines is 
dynamically woven into the particular class version. The routines are then 
invoked to return the results to the application. One might think that 
dynamic weaving (and reweaving) of instance adaptation routines, each 
time an incompatibility is encountered, actually increases the maintenance 
overhead. This is, however, not true. The overhead associated with dynamic 
weaving pays off in terms of localised changes and automatic propagation 
of changes through the weaver. In addition, the weaving overhead in 
SADES is significantly reduced by leaving an aspect woven and reweaving 
only when it is modified. The need to reweave is identified by a simple 
check based on timestamps. A detailed description of the weaver design and 
implementation is provided in Sect. 5.3.2. 

In order to trap interface mismatch messages and delegate them to the 
weaver to weave (or reweave), composition filters are employed (cf fig 
4.19). Composition filters are very effective in message interception and 
hence are an ideal choice for this purpose. An output dispatch filter inter- 
cepts any interface mismatch messages and delegates them to the weaver 
which then weaves (or reweaves) the appropriate instance adaptation rou- 
tines which are in turn invoked to return results to the application. 
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Fig. 4.19. Interception of interface mismatch messages and their delegation to the 
weaver using composition filters 



Fig. 4.20a uses the evolution scenario from Fig. 3.4 to demonstrate the 
use of instance adaptation aspects to modularise error handlers in SADES 
(note that as discussed in Sect. 4.2. 1.1 both the error handlers strategy and 
update/backdate methods strategy have been implemented in SADES). The 
age and height handlers for P e r s o n_V 1 have been omitted for simplifica- 
tion. Fig. 4.20b shows the definition of the address handler (in pseudo 
code) in the instance adaptation aspect in Fig. 4.20a. Fig. 4.20c shows (in 
bold) the parts of the aspect affected if the behaviour of the handler needs 
to be modified. This demonstrates that the aspect-oriented approach sup- 
ports localisation of changes by making it possible to modify the behaviour 
of the instance adaptation routines within the aspects instead of modifying 
them within each class version. It also reduces the maintenance overhead 
associated with propagation of customisation of the instance adaptation 
approach at the DBMS level as discussed in Sect. 4.4. This support for cus- 
tomisability has also made it possible to simulate an evolution primitive 
(not available in the SADES evolution taxonomy) to move attributes (e.g., 
migration of attributes from sub-class to super-class and vice versa) across 
classes in an information preserving fashion (Rashid and Sawyer 2001). It 
is not possible to carry out such a customisation in other object database 
evolution systems. 
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Fig. 4.21 shows that the instance adaptation layer in SADES exploits the 
functionality exposed by the versioning layer and the layer implementing 
links, referential integrity and change propagation. The links among class 
versions and aspects are implemented using relationship objects. The 
instance adaptation mechanism also makes frequent calls to the class ver- 
sioning mechanism during simulated or physical conversion across class 
versions (multiple class versions need to be referred to hence, requiring tra- 
versal through the version derivation graphs with the aid of the versioning 
mechanism). 




(a) 
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aspect Handlers 



join Points: all versions 
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join points: all versions 
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Fig. 4.20. Modularising error handlers in SADES using aspects (a) Addressing the evo- 
lution scenario in Fig, 3.4. (b) An aspect defining the address handler, (c) Changes to 
the aspect upon modifications to the address handler. 
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Fig. 4.21. Using hybrid AOP to implement the instance adaptation layer on top of the 
versioning layer and layer implementing links, change propagation and referential 
integrity 



4.33.2 Instance Adaptation Routines in AspOEv 

Before discussing the aspects encapsulating the instance adaptation rou- 
tines in Vejal, the language used for application programming in AspOEv, 
it is important to understand the versioning semantics in Vejal. Vejal has a 
two-level versioning identifier system (analogous to that used by the popu- 
lar free source code control system CVS (CVS 2003)). C [ 1 ] indicates class 
version 1 of class C while C [ s=l ] implies the class version of C that occurs 
in schema version 1. In Vejal, one version of a class may be present in mul- 
tiple schema versions. In order to prevent unworkable schema versions 
being created, a new version of a class can only be present in all the future 
schema versions in which it is still compatible with the contracts of the 
other classes in the schema. 

The instance adaptation aspects in Vejal are inspired by the instance 
adaptation implementation in SADES and aim to support the programmer 
to specify arbitrarily complex transformations between class versions. They 
are transparent view wrappers, written by the application programmer to 
present, e.g., an instance ofPerson[l] asaPerson [ 2], which are invoked 
by the runtime environment automatically whenever an object needs to be 
adapted to a different class version. Crucially, they work by transforming 
data at the field level, and do not attempt to emulate methods and nor do 
they require the application-specific evolution code to emulate methods. 
The “real” methods are always used from the Vejal class version required by 
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the application. Although this means an instance adaptation aspect breaks 
the encapsulation of the destination class version, this is arguably a good 
trade-off, because the alternative of emulating method behaviour leaves 
more room for error, and converting an object between class versions often 
requires knowledge of implementation details. There are no language 
restrictions on changes that can be made between one class version and the 
next. In particular, methods can be added, deleted and rewritten. 

Vejal instance adaptation aspects are intended to support either simu- 
lated or physical conversions with exactly the same aspect. This is in con- 
trast with SADES where the structure of instance adaptation aspects at the 
database level is determined by the instance adaptation aspect woven at the 
DBMS level. This is because the SADES aspect language and weaver have to 
operate within the constraints of Jasmine, the underlying object database 
management system, and Java, the SADES application programming lan- 
guage (Rashid and Sawyer 2000b). AspOEv, on the other hand, is a general 
framework that aims to support customisable evolution in any ODMG 
compliant (Cattell, Barry, et al. 2000) object database system and offers its 
own application programming language. 

Since Vejal instance adaptation aspects are independent of a particular 
instance adaptation approach, if the framework is configured (cf. Sect. 
4.2. 1.2) to use simulated conversions for a particular class, the instance 
adaptation aspect is used to project a compatible view. On the other hand, 
if physical conversion is required, the runtime environment “scans 
through” the aspect to physically convert the object to the new class. In 
either case, hidden fields are used, if required, to store data from previous 
schemas that should be invisible but may become visible upon another 
adaptation (Monk and Sommerville 1993). Thus no data is lost due to 
destructive conversions unless a previous schema is itself deleted. 



4.4 Change Propagation: DBMS Level to Database Level 

Fig. 4.22 shows how the aspect-oriented approach supports cost-effective 
propagation of a customisation from the DBMS level to the database level 
in SADES. As shown in the figure, the effect of any customisation to the 
instance adaptation approach (at the DBMS level) is limited to the aspects 
encapsulating the instance adaptation routines (at the database level). This 
is in direct contrast with the scenario in Fig. 3.4 where customisation of the 
instance adaptation approach, if at all possible, would trigger the need for 
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modifications to all the versions of existing classes in the database. Note 
that, as discussed in Sect. 4.3. 3.2, the customisation of the instance adapta- 
tion approach in AspOEv has no impact at the database level. 
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Fig. 4.22. Localised impact of propagation of customisation from the DBMS level to the 
database level in SADES. 



4.5 Cost-effectiveness 

Since AOP techniques are fairly new, there are very few empirical evaluations 
available, e.g., (Murphy, Walker, et al. 1999; Baniassad, Murphy, et al. 2002). 
In the case of application of AOP to database systems quantitative data is only 
available from the case study^ carried out to evaluate SADES (Rashid 2000a; 
Rashid 2002a). This quantitative evaluation shows that the localisation of 
changes in SADES is twofold or greater over existing systems for most cust- 
omisation scenarios. In some cases the improvement offered by SADES is as 
high as fourfold. The bar charts in Fig. 4.23 demonstrate this cost-effective- 
ness in comparison with two other object database evolution systems. 



4.6 Conclusion 

This chapter discussed the application of aspect- oriented programming 
techniques to database systems and provision of localised changes during 
customisation without compromising the benefits of closely woven designs. 



5. The case study is based on evolution scenarios from an adult education organisation 
where the database is central to the day-to-day activities. 
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The effectiveness of the aspect-oriented approach was discussed through 
concrete examples of modularisation of crosscutting concerns in three sys- 
tems: SADES, AspOEv and GOODS. It was demonstrated that aspect-orien- 
tation provides a high degree of customisability at both the DBMS level and 
the database level in a cost-effective fashion. The impact of changes during 
propagation of customisation from the DBMS level to the database level is 
localised hence, reducing the associated maintenance overhead. Customisa- 
tion is possible at both compile-time and run-time, and at different compo- 
nent granularities. Although the systems discussed in this chapter are object- 
oriented database systems, the concepts and approaches can be applied to 
other types of database systems particularly object-relational ones. 
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Fig. 4.23. Bar charts showing quantitative evaluation of SADES (a) Number of entities 
(meta- objects and/or aspects) affected due to changes to links during various schema 
evolution operations, (b) Number of entities (class versions and/or aspects) affected 
upon customisation of instance adaptation routines. 

The customisation approach discussed in this chapter heavily relies on 
weaver efficiency. One of the key research issues is the development of cor- 
rect and efficient weaving mechanisms. Efficiency is particularly critical for 
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dynamic weaving as it introduces additional overhead at run-time and can 
be feasible only with efficient weavers. AOP research, to date, has mainly 
focussed on the development of AOP techniques, their correctness and 
design issues for aspect languages. The efficiency and correctness of weavers 
will be the determining factors for commercial feasibility of AOP and hence, 
need extensive research. Section 5. 3.2.2 discusses the potential of selective 
weaving (Rashid 2002b) (also known as incremental reweaving) - weaving 
only the modified or previously unwoven parts of an aspect instead of the 
whole aspect itself - for the purpose. 




5. Persistent Aspects 



This chapter focuses on how database systems can support aspect- oriented 
development by providing effective means for aspect storage, retrieval and 
manipulation. Section 5.1 motivates the need for aspect persistence. Section 
5.2 discusses the design and implementation of persistent aspect stores based 
on object-oriented and relational databases. Section 5.3 addresses the issue 
of aspect composition in a persistent environment. Two composition mech- 
anisms are discussed: one employs the weavers available for existing aspect 
languages while the other is based on building the weaving functionality into 
the database management system. Some existing applications making use of 
persistent aspects are discussed in Sect. 5.4 before concluding the discussion 
in Sect. 5.5. 



5.1 Need for Aspect Persistence 

Work on lifetime of aspects (Kiczales, Lamping, et al. 1997; Matthijs, 
Joosen, et al. 1997; Kenens 1998; Pawlak, Seinturier, et al. 2001; Popovici, 
Gross, et al. 2002) has argued that at least some of the aspects should live 
for the lifetime of the program execution and not die at compile-time. In 
certain cases the need for aspects to outlive the program execution can 
arise. The database level aspects discussed in Sect. 4.3 are persistent by 
nature as they cut across persistent entities (meta-schema, schema and data 
elements). Due to the close integration between object-oriented program- 
ming languages and object-oriented databases these aspects are seamlessly 
used by application programs. There is, therefore, a need to manage the 
storage, retrieval and composition of these aspects. Other scenarios requir- 
ing the need for an aspect repository have been highlighted. The use of an 
aspect repository, similar to a CORBA interface repository, for managing 
and reusing aspects in a distributed environment has been proposed in 
(Pulvermueller, Klaeren, et al. 1999). The approach aims at reducing the 
additional complexity introduced due to the need to find an aspect in a net- 
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work of computing units. Aspects in the repository are persistent and appli- 
cations at different locations can query the repository to retrieve the 
required aspects at run-time (cf. Fig. 5.1). 

Another motivation for an aspect repository is to treat aspects as a soft- 
ware asset in an organisation and promote aspect reuse. The mining and 
reuse of existing assets is a core activity in the engineering of large, complex 
software systems and a driving factor in the reduction of their costs and 
time to market. Code repositories are at the nucleus of this activity making 
it possible to reuse existing program modules, adapt them to new problem 
contexts and, mine and extract parts of different modules reusable in the 
development of a new one. It is, therefore, essential that support for storage 
and retrieval of program modules in code repositories remains in step with 
the emergence and adoption of new programming paradigms. This trend 
can already be observed in several proposals on the need for component 
repositories to support component-based development, e.g., (Weyuker 
1998; Rashid and Kotonya 2001). Similar benefits can be derived in terms 
of aspect reuse by treating them as a software asset. By having aspects avail- 
able which have specified tasks and attributes that can be used system-wide 
we can reuse them with little or no alteration in other systems. As pointed 
out in (Clarke and Walker 2001a), several aspects follow easily recognisable 
patterns and so can be adapted relatively easily to new contexts. An example 
of this would be the observer pattern or a simple tracing aspect that logs the 
instantiations and calls exhibited by a system during testing. The existence 
of such reusable (and adaptable) patterns further strengthens the argument 
for aspect storage and mining. However, for such variation and reuse to be 
effective it is essential that not only suitable aspects are retrieved but also 
support is available to help determine their original context of use and their 
influence within the new application context. This is critical as with mech- 
anisms such as pattern matching employed in techniques such as Aspect} it 
is possible that reuse will result in matching modules to which the aspect’s 
behaviour should not apply or ignoring modules to which it should. It is 
also worth noting that, since aspects capture system-wide properties, their 
storage as an asset makes it possible to query program modules in an asset 
repository based on their global properties. 

The existence of persistent aspects also triggers the need to provide com- 
position mechanisms that are aware of the fact that aspects live beyond pro- 
gram execution and may be modified from other applications. 
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Location C 



Fig. 5.1. Managing and reusing distributed aspects through an aspect repository 
(adapted from (Pulvermueller, Klaeren, et al. 1999)) 



5.2 Persistent Aspect Stores 

This section discusses the design and implementation of persistent aspect 
stores based on object-oriented and relational database systems. As shown 
in Fig. 5.2, persistent storage of aspects in object-oriented databases 
requires reifying them as first class objects. While there are a number of 
other considerations (cf. Sect. 5.2.1), the reification is intuitive as aspects, 
like objects, have both state and behaviour. In contrast, persistent storage 
of aspects in relational databases, poses the familiar impedance mismatch 
problem (Elmasri and Navathe 2000). Aspects need to be dismantled for 
storage in the database and reassembled upon retrieval. 




Fig. 5.2. Constrasting persistent storage of aspects in object-oriented and relational 
databases 
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The following discussion provides examples of two concrete aspect 
stores, one based on the Jasmine object-oriented database (Jasmine 1996) 
and the other employing SQL-92 compliant relational databases. Both 
aspect stores support persistent storage of AspectJ aspects. 



5.2.1 An Aspect Store Based on an Object-Oriented Database 

Any aspect persistence mechanism based on an object database must 
account for the constraints imposed by the ODBMS, and the AOP approach. 
While some of these constraints might be specific to the particular ODBMS 
or AOP technique, there are several general constraints which have been 
summarised below: 

• Constraints imposed by ODBMSs 

Object database management systems often require that classes whose 
instances are to be stored in the database extend a system provided 
persistent root class. These classes are then augmented by persistence- 
related code using a persistence processor at the pre-compilation or 
post-compilation stage. Examples of such systems include the Object 
Data Management Group (ODMG) standard (Cattell, Barry, et al. 
2000), 02 (02 1998) and Jasmine (Jasmine 1996). 

Due to proprietary restrictions it is not possible to modify the system 
classes implementing the persistence model of the object database 
management system being used. 

Most object database management systems employ the persistence by 
reachability principle (Elmasri and Navathe 2000). When a transac- 
tion commits, all objects reachable from a persistent object are transi- 
tively made persistent. Examples of such systems include the ODMG 
standard (Cattell, Barry, et al. 2000), 02 (02 1998), Jasmine (Jasmine 
1996) and Object Store (ObjectStore 1996). 

• Constraints imposed by aspect languages and weavers 

The aspect structures can vary considerably across AOP techniques. 
Some AOP approaches and their associated composition mechanisms 
might support run-time aspects while others might not. 

AOP approaches and aspect structures are continuously evolving as 
AOP technologies mature. 
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The model for aspect persistence based on an object database is shown 
Fig. 5.3. The model operates within the above constraints and is an adapta- 
tion of the aspect persistence model proposed in (Rashid 2000b). The per- 
sistent root class offered by the ODBMS API is extended by a surrogate per- 
sistent root class. All application classes whose instances are to be stored in 
the object database extend the surrogate persistent root class and hence, indi- 
rectly, extend the persistent root class. The surrogate persistent root class pro- 
vides methods which are invoked each time an object is made persistent. 
This is achieved by providing wrappers around the ODBMS transaction 
operations. This mechanism has been preferred over using reflective mech- 
anisms, if present in the OO language, to obtain information about the per- 
sistent root class. This is because one cannot be sure about the methods of 
the persistent root class invoked upon object persistence and the order of 
their invocation. 

The invocations of the surrogate persistent root class methods upon object 
persistence provide suitable join points for the persistent root aspect. This 
aspect intercepts these invocations and ensures that all aspects reachable 
from the persistent object are transitively made persistent. All application 
aspects that cut across persistent objects extend the persistent root aspect. 
The surrogate persistent root class, persistent root aspect and aspect persis- 
tence by reachability provide a non-intrusive, natural extension of the per- 
sistence model employed by several ODBMSs. Hence, the restrictions 
imposed by the nature of ODBMSs and their APIs are effectively dealt with. 

When a transaction commits all aspects reachable from a persistent 
object are made persistent. As shown in Fig. 5.4, aspect 1 is an instance of an 
aspect extending the persistent root aspect and reachable from a persistent 
object object 1. It is, therefore, made persistent. Although aspect 2 is also an 
instance of an aspect extending the persistent root aspect it will not be made 
persistent as it is not reachable from any persistent objects in the scope of 
the transaction. Aspect 3 poses an interesting scenario. It is reachable from 
a persistent object but is not an instance of an aspect extending the persistent 
root aspect. It will be coerced into persistence in order to preserve persis- 
tence by reachability. The coercion strategy can be to force the aspect to 
extend the persistent root aspect or to annotate the particular aspect instance 
{aspect 3) with persistence-related code. The choice of coercion strategy has 
been left to the implementation of the model. It should be noted that aspect 
persistence by reachability is transitive in nature, i.e., not only aspects reach- 
able from persistent objects are made persistent but also aspects reachable 
from persistent aspects are transitively made persistent. 
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Fig. 5.3. Integration of the aspect language and the OO language API offered by the 
ODBMS 




Fig. 5.4. Aspect Persistence by Reachability 

In order to deal with the evolving nature of AOP techniques all links 
between aspects and classes have been kept strictly class directional i.e., the 
aspects know about the classes but not vice versa (Kersten and Murphy 
1999). This localises changes resulting from the evolution of the AOP 
approach making maintenance and modifications to the persistence model 
inexpensive. Such changes are further aided by the aspect persistence aspect 
which separates the persistence approach from the persistent aspects - per- 
sistence is a crosscutting concern in a system (Mens, Lopes, et al. 1997; 
Suzuki and Yamamoto 1999b). It also encapsulates any language or weaver 
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specific features that need to be incorporated into the model. As a result 
changes that do not affect aspect reachability are localised to the aspect per- 
sistence aspect. This also makes it possible to keep the AOP approach and 
ODBMS API integration model largely independent of the particular AOP 
approach as features specific to the AOP technique are mainly encapsulated 
in one single aspect \ 

5.2.1 .1 PersAJ: An Aspect Store Based on Aspect! and Jasmine 

PersAJ (Persistent Aspect J), is an implementation of the persistence model 
using Aspect} 0.7betal2 and the Jasmine (1.21) object database manage- 
ment system from Computer Associates. The implementation is shown in 
Fig. 5.5. It should be noted that the figure only depicts the code relating to 
the description in Sect. 5.2.2. Other implementation code has been omitted. 

P RC is the persistent root class in the Jasmine Persistent Java binding (pj). 
PObject is the surrogate persistence root class and has a special instance- 
level method called pens 1 st ( ) which is invoked for all persistent objects 
(identified through persistence by reachability) just before a transaction 
commits. PAspectis the persistent root aspect and determines all reachable 
aspects from a persistent object after the persist ( ) method has been 
invoked (upon transaction commit). The reachability from an object is 
explicitly specified in each sub-aspect of PAspect through a static advice. 
All reachable aspects are made persistent through a call to the pe r s 1 s t ( ) 
method for the aspect instance. The pe r s 1 s t ( ) method is introduced into 
PAspect by the AspectPersistence aspect. 

Note that this implementation was initially carried out using Aspect} 0.6 
beta 2 and later ported to Aspect} 0.7 beta 12. This provided an opportunity 
to reflect on the effectiveness of the persistence model in coping with 
changes to the aspect language. The class directional nature of the aspects 
made it possible to make all the changes without affecting existing applica- 
tion classes. The Aspect} 0.6 beta 2 implementation relied on the explicit 
instantiation of an aspect followed by its addition to the aspect list of an 
object to determine reachability (by calling the get Aspects ( ) method on 
an object). These features were dropped in Aspect} 0.7 beta 12 in favour of 
automatic maintenance of links between aspects and objects and disallow- 
ing of explicit aspect instantiation. Although changes were localised to the 
aspects, it was decided to maintain reachability links explicitly in the model 

1. Note that it is not possible to achieve full independence from the features of the AOP 
approach as the persistent root aspect and aspect persistence by reachability will 
employ these features. 




98 5. Persistent Aspects 



implementation to further reduce the evolution complexity should such 
changes occur in the language in the future. All other changes to the lan- 
guage were localised to the AspectPeristence aspect. This effective local- 
isation of changes indicates that the proposed mechanism is capable of 
effectively coping with the presently evolving nature of aspect languages 
and weavers. 

Aspect Persistence ^ 

// uihtr impkmenrjilioji specific code 

inlrvduction I* Aspect f 
\gid persistQ ( 

U method code 

^ J 




Fig. 5.5. PersAJ: An implementation of the persistence model using Aspect} 
(0.7betal2) and Jasmine (1.21) 
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5.2.2 An Aspect Store Based on a Relational Database 

Section 5.2.1 described a reification-based model for storage and retrieval of 
aspects in object databases. The focus of this section is on the use of rela- 
tional database systems to support storage and retrieval, and hence, mining 
and reuse, of aspects. The need for a relational aspect store is driven by the 
major share of the database market claimed by relational systems and, there- 
fore, significant amount of existing investment in such systems on part of 
software development organisations. The relational aspect store is based on 
mapping the aspect structure to relational tables which are used to store the 
aspects. This is in contrast with the more generally used approach to build- 
ing code repositories where code is stored in BLObs (Binary Large Objects) 
or CLObs (Character Large Objects) together with meta-data which is used 
to retrieve or mine the code. The reasons behind the choice of fine-grained 
mapping instead are as follows: 

• The conventional approach results in loss of actual code representation 
hence, constraining queries and, consequently, the mining process to the 
meta-data. If the information required by the mining process cannot be 
derived from the meta-data, it is not possible to run arbitrary queries 
against the binary code. The queries become too complex in case of 
CLObs and are hard to formulate due to the lack of a formal structure, 
e.g., a relational schema. Explicitly capturing the code structure of an 
aspect makes it possible to run fine-grained queries offering more flexi- 
ble aspect mining capabilities. Fine-grained queries on the code repre- 
sentation are particularly useful to support extracting parts of different 
existing modules (aspects in our case) to be reused in the development 
of a new one. Support for fine-grained querying also makes it possible to 
identify an aspect’s original application context and its influence in the 
reuse context. This, in turn, supports validation of the aspect in its reuse 
context. 

• Specification of meta-data for aspects is a difficult task due to the their 
crosscutting nature. 

• As discussed in Chap. 2, a number of AOP techniques are available, e.g., 
aspect languages, composition filters, adaptative programming, hyper- 
paces, etc. Each approach supports a conventional base programming 
language, e.g.. Aspect! is an aspect language for Java. If aspects are stored 
as BLObs they are limited to use within the particular AOP approach 
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they are implemented in. However, if their structure is captured it is pos- 
sible to use mapping algorithms, e.g., (Chavez, Garcia, et al. 2001; Clarke 
and Walker 2001b), to reuse or adapt them for a project employing a dif- 
ferent AOP approach. This, in turn, provides an opportunity to evolve 
the relational schema into a common persistent aspect representation 
(Rashid 2000b) complemented by algorithms for mapping the persistent 
representation to aspect structures in different AOP techniques. 

S.2.2.2 An Aspect Store for AspectJ using SQL-92 Databases 

This section describes a relational aspect store based on mapping AspectJ 
1.0 aspects to relational tables in any SQL-92 compliant relational database 
and execution of fine-grained queries on the stored aspects. AspectJ has 
been chosen because it has the largest user base among the available AOP 
techniques. Note that while some algorithms for mapping AspectJ aspects 
to some other techniques exist (e.g., (Chavez, Garcia, et al. 2001; Clarke and 
Walker 2001b)) such mapping is not discussed here. 

From the anatomy of an AspectJ aspect shown in Fig. 5.6 (reproduced 
from Fig. 2.3), we can identify three main constructs in an aspect (ignoring 
ordinary Java members): named pointcuts, advices and introductions. As 
discussed in Sect. 2.2.1, an advice may or may not be related to a named 
pointcut; an advice can be defined independently of a named pointcut in 
which case an implicit pointcut comes into existence. This leads us to the 
definition of our initial high-level mapping of an aspect structure to a rela- 
tional schema. This mapping is shown in Fig. 5.7. 
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Fig. 5.6. Anatomy of an AspectJ aspect and an example aspect in AspectJ (1.0) 
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Fig. 5.7. High-level aspect table structure prior to further decomposition 

The next step in the mapping is further decomposition of the initial 

high-level relational schema. This is essential for a number of reasons: 

• We should aim to achieve a decomposition compliant with Boyce-Codd 
normal form hence, adhering to established good design practices for 
relational database systems. 

• As discussed earlier, detailed mapping of an aspect structure to a rela- 
tional model makes it possible to run fine-grained queries which are par- 
ticularly useful to support extracting parts of different existing aspects to 
be reused in the development of a new one. In addition, it makes it pos- 
sible to use mapping algorithms to reuse the aspect in an AOP technique 
other than the one used to develop it. 

• AOP is a new paradigm and, like all other AOP techniques. Aspect} is 
continuously evolving. Having a fine-grained mapping makes it easier to 
evolve the relational schema in step with changes in Aspect}. The experi- 
ence with evolving PersA}, the persistent aspect store for Aspect} based 
on }asmine (discussed in Sect. 5.2. 1.1) demonstrates that the evolving 
nature of AOP techniques is a very important consideration in the 
design. 
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Fig. 5.8. Fine-grained mapping of aspect anatomy to the relational schema 



The various tables and their relationships in the fine-grained mapping 
are shown in Fig. 5.8 while the detailed structure of each table is shown in 
Fig. 5.9. The data to be stored is obtained through an API developed for the 
Aspect! 1-0 parser. The API supports traversal through the structure of an 
aspect and access to detailed information about its components (advices, 
pointcuts, etc.). 
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Fig. 5.9. Detailed structure of each relational table in the mapping 



5.2.2.2.1 Mapping Example 

This section discusses the structure of the various tables and rationale 
behind some of the design choices by discussing the mapping of our example 
aspect from Fig. 5.6 to the relational schema. When showing the mapping, 
the tables and the attributes not used in our example aspect are omitted. 

The Aspect_Root table captures the information that relates to the 
aspect at the top-most level, e.g., the Java package the aspect belongs to, 
whether it is pri v1 1 eged to access private members of classes in the pack- 
age and other aspects that it might extend. This table also provides an 
opportunity to capture some additional meta-data about the aspect, e.g., a 
timestamp showing when the aspect was created. Note that the inheritance 
relationship (extends) is captured within the Aspect_Root table while 
the relationship with other aspects over whose behaviour an aspect has a 
higher execution priority (dominates) is captured separately in the Dorn 1 - 
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nates table. From the viewpoint of the aspect specifying the relationships, 
these are both one-to-many relationships. Fiowever, they are stored differ- 
ently because of the following reasons: 

• An additional Extends table will be redundant as the link in the 
As pect_Roo t table already represents the many edge of the relationship, 
i.e., there are links from all the sub-aspects to the super-aspect but not 
vice versa. Storage of a new aspect does not require additional operations 
as no references in its super-aspect record need to be updated. 

• Capturing the dominates relationship within the Aspect_Root table 
will in fact equate to capturing the dominatedjby relationship. This will 
mean that when a new aspect is stored in the database all the 
dominatedjby links will need to be updated. It is more efficient to store 
the relationship with reference to the aspect it was specified in. 

• While dominates might appear a one-to-many relationship from the 
viewpoint of the aspect in which it is specified, in fact it can be an inverse 
many-to-one relationship from the viewpoint of the aspect dominated. 
This is because multiple aspects can specify a relationship to dominate 
the same aspect. 

In case of our example aspect, the information in the Aspect_Root table 
is shown in Table 5.1. 

Table 5.1. Information stored in the Aspect_Root table for the example aspect 



ASPECT_Root 




AS_ID Name 


Timestamp 


1 ExampleAspect 


07 Mar. 2002 14:45 



The Ad V i ce_Root table captures the advice type (before, after, etc.) and 
the code to be executed at the join points it operates on. It also relates to the 
aspect which defines the advice through the aspect identifier: AS_I D. If the 
advice uses a named pointcut, the N PCT_I D attribute is used to relate to the 
appropriate pointcut in the Named_Poi ntcut table. Note that although 
advices and named pointcuts are strongly related they have been modelled 
separately due to the following reasons: 

• Named pointcuts do not need to model the advice type (before, after, 
etc.). This is because the advices depend on the pointcut but not vice 
versa. 




5.2 Persistent Aspect Stores 105 



• Named pointcuts can also reference other named pointcuts^ (hence, the 
recursive link in Fig. 5.8). 

Parameters for the advice and the named pointcut usage in the advice are 
mapped using the NamedPoi ntcut_Pa rameters and Advi ce_Para- 
meters tables. Tables 5.2 - 5.5 show the Advi ce_Root, Named_Poi ntcut, 
NamedPoi ntcut_Parameters and Advi ce_Pa rameters tables for our 
example aspect. 



Table 5.2. Information stored in the Advi ce_Root table for the example aspect 



ADVICE. 


_Root 








AD_ID 


AS_ID 


AdviceType 


Code 


NPCTJD 


1 


1 


before 


// some code 


1 


2 


1 


after 


// some code 


<null> 



Table 5.3. Information stored in the Named_Poi ntcut table for the example aspect 



Named_Pointcut 



NPCTJD AS_ID Name 

1 1 pci 



Table 5.4. Information stored in the Named_Poi ntcut_Pa rameters table 
for the example aspect 



N amedPointcut_Parameters 


PRMJD 


NPCTJD 


ObjectType 


Name 


Target 


1 


1 


Connection 


c 


c 


Table 5.5. 


Information stored in the Advi ce 


_Pa rameters table 


for the example aspect 








Advice_Parameters 


PRMJD 


AD_ID 


ObjectType 


Name 


Target 


1 


1 


Server 


s 


s 


2 


2 


Connection 


a 


a 



The Pri mi t1 ve_Po1 ntcut_Des1 gnators table captures single join 
points and relates them to the appropriate named pointcut or advice oper- 
ating upon them. The Compound_Poi ntcut_Des1 gnators table captures 

2. Note that named pointcuts can also be referenced by implicit pointcuts. 
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the compound pointcuts formed from the primitive ones and the combina- 
tional logic involved. The mapping of compound pointcuts and capturing 
of the combinational logic is one of the main challenges encountered in the 
database design. This is because it is not possible to perceive the complexity 
of a compound pointcut or its combinational logic as these depend on the 
preferences and programming styles of individual developers. In the cur- 
rent design this problem has been addressed by storing details of opening 
and closing brackets in such a statement in attributes within the 
Compound_Po1 ntcut_Des1 gnators table. While this is not the most ele- 
gant of designs and leads to highly syntactic mapping, it can store even the 
most complex of statements effectively and cater for diverse programming 
styles. A neater yet effective design of this feature is planned in the future 
(Rashid and Loughran 2002). 

Our example aspect only uses primitive pointcut designators (cf. Table 5.6). 

Table 5.6. Information stored in the Pri m1 1 1 ve_Poi ntcut_Des 1 gnators table 
for the example aspect 



Primitive_Pointcut_Designators 



PPCTD_ID 


AD_ID 


NPCT_ID 


PTCTD_Type 


MJPJD 


1 


<null> 


1 


call 


1 


2 


1 


<null> 


call 


2 



The Method_Jo1 n_Poi nt and Fi el d_Joi n_Po1 nt tables capture the 
details of each join point, i.e., the method and field signature. Our example 
aspect only specifies behaviour for method join points (cf. Table 5.7). 

Table 5.7. Information stored in the Method_Joi n_Poi nt table 
for the example aspect 



Method_Join_Point 


MJPJD 


Modifier 


ReturnType 


ObjectCut 


MethodName 


Parameters 


1 


public 


void 


Connection 




String 


2 


public 


String 


Server 


getAddress 


<null> 



The I ntroducti on_Root table captures general information about the 
introduced fields and methods, e.g., modifiers, type or return type and 
relates these to the Introducti on_Fi el ds and I ntroducti on_Methods 
tables which capture the details of the introduced fields and methods. The 

Introduction Method Parameters table stores information about 
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parameters of introduced methods while the Introduct1on_0bjectCuts 
table captures the object types into which the methods and fields are intro- 
duced. Tables 5.8 - 5. 12 show the introduction information from the exam- 
ple aspect stored in the relational aspect store. 

Table 5.8. Information stored in the Introducti on_Root table 
for the example aspect 



Introduction_Root 


INJD AS_ID 


Modifier 


ReturnType 


FLDJD 


MTHDJD 


1 1 


private 


boolean 


1 


<null> 


2 1 


public 


void 


<null> 


1 



Table 5.9. Information stored in the Introducti on_Fi el ds table 
for the example aspect 



Introduction_F ields 


FLDJD 


FieldName 


Value 


1 


disabled 


false 



Table 5.10. Information stored in the Introducti on_Methods table 
for the example aspect 



Introduction, 


.Methods 




MTHDJD 


MethodName 


Code 


1 


printMessage 


// some code 



Table 5.11. Information stored in the Introduction_Method_Parameters table 
for the example aspect 

Introduction_Method_Parameters 

PRM_ID MTHD_ID ObjectType Name 

1 1 String m 

Table 5.12. Information stored in the Introducti on_0bj ect Cuts table 
for the example aspect 



Introduction_ObjectCuts 


OBJ_ID 


INJD 


ObjectCut 


1 


1 


Connection 


2 


2 


Client 


3 


2 


Server 
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5.2.2.1.2 Query Support: Processing and Translation to SQL 

A GUI tool has been developed to support the querying and retrieval of 
aspects from the repository. As discussed below, the queries from the GUI 
tool are translated to SQL for processing against the repository. Conse- 
quently, an expression builder can be used to bypass the GUI and support 
an experienced developer in forming his/her own queries. Another key fea- 
ture of the tool is support for extracting advice and introductions alone as 
well as whole aspects. 

The querying support can be demonstrated by showing a simple query 
that a user might put together. The query is as follows: 

Retrieve an aspect which employs: 

- an after advice that takes in Server object types as a parameter; 

- uses a call pointcut designator on methods called getAddress; 

- introduces public methods on Client objects. 

Figures 5.10 a through c show the steps involved using the GUI. 



Simple Query 



Abject I AdvKe | Iritroduiiion | Exprsssurt Builder j JDBC Setup | 

R Aspect 



r 


PriveSeged 


Modifier f 


r 


Final 


Donmates ; 


r 


Abstract 


Mmed : r 


r 


Static 


Extern ; f 






Package i f 






dear Query j Process Queryl | 



Fig. 5.10 a. Example query step 1 
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Fig. 5.10b. Example query step 2 




Fig. 5.10c. Example query step 3 

The data provided by the user is extracted from the GUI and appropriate 
SELECT, FROM and WFiERE clauses are generated. The retrieval of the 
aspect code from the database is a two step operation: 
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1. Assemble and execute the SQL using the GUI as previously described in 
order to return the key IDs in the result set. 

2. Using the key IDs obtained in the first step create a number of SQL queries 
to retrieve result sets in order to recreate the aspect/advice/introduction. 

In the case of the example query the SQL clauses generated for step 1 are 
as follows. The Aspect ID obtained can then be used to create other SQL 
queries to retrieve appropriate parts of the aspect in order to recreate it. 

SELECT clause: 

Aspect_Root . AS_ID 

FROM clause: 

In the example query the following tables were determined to be used in 
this clause: 

Aspect_Root 

Advi ce_Root 

Advi ce_Parameters 

Pri mi t1 ve_Poi ntcut_Desi gnators 

Method_Joi n_Poi nt 

Introducti on_Root 

Introductl on_Method 

Introducti on_0bjectCuts 

WHERE clause: 

The relevant keys are joined and the data entered/selected in the GUI 
added to the WHERE string as follows: 

Aspect_Root . AS_ID = Advi ce_Root . AS_I D AND 

Aspect_Root . AS_ID = Introducti on_Root . AS_I D AND 

Advi ce_Root . AD_ID = Advi ce_Pa rameters . AD_I D AND 

Advi ce_Root . AD_ID = Primi ti ve_Poi ntcut_Desi gnators . AD_ID 

AND 

Primi ti ve_Poi ntcut_Desi gnators .MJP_ID = 
Method_Join_Point.MJP_ID AND 

Introducti on_Root . I N_ID = Introducti on_0b j ect_Cuts . I N_I D 
AND 

Introducti on_Root .MTHD_ID = Introducti on_Methods . MTHD_I D 
AND 

Advice_Root.AdviceType = ’after’ AND 

Advi ce_Parameters .ObjectType = ‘Server’ AND 

Pri mi ti ve_Poi ntcut_Desi gnators . PTCTD_Type = ‘call’ AND 

Method_Join_Point.MethodName = ‘getAddress’ AND 

Intrducti on_0bjectCuts .ObjectCut = ‘Client’ 
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53 Aspect Composition in a Persistent Environment 

This section discusses two mechanisms for weaving aspects in persistent 
environments. Object databases are employed as the basis for the discus- 
sion. The first mechanism is based on exploiting existing aspect languages 
and their associated weavers while the second mechanism is based on build- 
ing weaving functionality into the database management system. The two 
mechanisms address different application areas. The first mechanism 
addresses the needs of the database application developer while the second 
caters for the needs of the database administrator and maintainer. 



5.3.3 Exploiting Composition Mechanisms of Existing AOP Techniques 

The model in Fig. 5.3 provides integration between the AOP technique and 
the OO language API offered by the ODBMS. It does not describe the actual 
weaving process in this persistent environment nor does it discuss how the 
varying support for run-time aspects across aspect languages and weavers 
is catered for. The weaving process is shown in Fig. 5.1 1. The nature of the 
transformation pipeline in this process automatically accounts for the fact 
that not all weavers support run-time aspects. 



Application at Application at 

Compile-time Run-time 




Fig. 5.1 1. Weaving in an object database based persistent environment using an existing 
weaver 



The transformation pipeline is composed of three code generators: 

The aspect weaver takes the aspect and class definitions and merges them 
with respect to the join points (assuming pre-compilation weaving). 
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• The modulator removes any syntactic mismatches between the code 
produced by the aspect weaver and the code to be supplied to the persis- 
tence pre-processor (assuming pre-compilation processing). 

• The persistence pre-processor takes the modulated woven code and 
generates persistence capable code and the database schema. 

The persistence capable code from the transformation pipeline is fed to 
the language compiler which compiles the code to an executable format. 
Note that if the aspect language and weaver support run-time aspects these 
would be reified as objects together with the woven structures. As a result 
the persistence pre-processor will automatically generate persistent repre- 
sentations for both woven structures and the reified aspects. The applica- 
tion will, therefore, be able to access these reified aspects together with the 
objects at run-time through the ODBMS API (integrated with the aspect 
language as discussed in Sect. 5.2.1). If the aspect language and weaver do 
not support run-time aspects the persistence processor will automatically 
generate persistent representations for woven structures only (as these will 
be the only input from the weaver). As a result aspects will not be available 
to the application at run-time. Note that the persistent representation of an 
aspect (if it can live beyond compile-time) is automatically determined by 
the persistence processor (as the aspect is reified as an object). The applica- 
tion programmer does not need to concern him/herself with this issue. 

In case of PersAJ, the modulator only replaces any $ signs in the code 
generated by the Aspect} weaver as this is regarded a reserved character in 
Jasmine and hence, its persistence pre-processor. 



5.3.2 Building Composition Mechanisms into the DBMS 

The mechanism discussed in Sect. 5.3.1 provides a means for database 
application programmers to use existing aspect languages and weavers in 
an object database environment. However, there are other roles in a data- 
base environment, e.g., database administrators and maintainers^. These 
roles often perform maintenance or maintenance-related activities. It is, 
therefore, imperative that they benefit from the effectiveness of AOP in 
localisation of changes to crosscutting features (hence, reducing mainte- 
nance overheads). Very often advanced maintenance features are available 
through programming interfaces based on proprietary languages. For 



3. Note that the same person can play the different roles. 




5.3 Aspect Composition in a Persistent Environment 113 



instance, both 02 (02 1998) and Jasmine (Jasmine 1996) offer advanced 
schema evolution functionality through proprietary languages 02C and 
ODQL respectively. As a result, use of existing aspect languages and weavers 
is not an option. If the DBMS developer chooses to offer the benefits of 
aspect-orientation to these roles then aspect languages and weavers for pro- 
prietary languages need to be built into the DBMS. 

When building an aspect weaver into a DBMS the following factors must 
be taken into account: 

• The aspect weaver must be aware of the fact that aspects may be persis- 
tent. This differs from the mechanism in Sect. 5.3.1 where an aspect lan- 
guage integration mechanism and a transformation pipeline shield the 
weaver from the persistent nature of aspects. 

• The aspect weaver needs to provide a persistent structure for the aspects 
(instead of relying on a transformation pipeline for the purpose). 

• The aspect weaver might need to retrieve and weave the aspects before 
information is delivered to an application. Examples of such aspects are 
instance adaptation and links among persistent entities (cf. Sect. 4.3). 
While the DBMS uses these aspects to reduce maintenance overhead the 
application does not need to be aware of their existence and can simply 
use the woven structures. 

• Aspects might be modified after they have been woven. 

5.3.2.1 Persistent Aspect Structures 

Three different persistent aspect structures may be employed by a weaver in 
an object database environment. Each of these has its advantages and dis- 
advantages: 

1. Aspects are reified as first-class persistent objects. Instead of modifying 
the code of classes the weaver simply delegates control to the aspects 
when a join point is encountered (Boellert 1999; Czarnecki and Eise- 
necker 2000). The advantage of this approach is that full reflective infor- 
mation about the persistent aspects is available. However, it is most suit- 
able in situations where aspects may be repeatedly modified. Otherwise 
the delegation overhead can be significant because, unlike weaving 
approaches based on code modification, code optimisations cannot be 
applied. 

2. Reify the aspect as a first-class persistent object but weave it into the code 
when required. The advantage of this approach is that full reflective 
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information is available about the persistent aspect prior to weaving. 
Code optimisations can be applied when the aspect is woven. However, 
post-weaving reflective information is not available. 

3. Simply store the aspect code as described by the aspect language in the 
database. When required, the code can be retrieved and woven into the 
class code. This mechanism is very efficient as no reflection overheads are 
involved and code optimisations can be applied. However, this also 
means that no reflective information is available prior to or after weaving. 

53.2.2 Weave-on-demand and Weave Histories 

As mentioned earlier, aspects may be modified after they have been woven. 
As a result, the weaver needs some mechanism to propagate the changes in 
the aspect definition to its woven state. If the weaving mechanism is based 
on code modification (structures 2 and 3 in Sect. 5.3.2. 1), the reweaving 
overhead can be significant hence, compromising the advantages gained 
from applying code optimisation. The following two mechanisms can be 
employed, in conjunction, to deal with the changing nature of aspects and 
propagate these changes in an efficient manner in weaving approaches 
based on code modification: 

• Weaving on-demand: An aspect is woven only if it has not been previ- 
ously woven. An aspect is rewoven only if it has been modified since the 
last weave. 

• Maintaining weaving history: Once an aspect is modified its previous 
definition is saved. This is referred to during reweaving by the weave-on- 
demand process as the previous definition needs to be unwoven before 
the new one is woven. 

A weaving process using weaving on-demand and weaving histories is 
shown in Fig. 5.12. As shown in the figure, each aspect maintains the fol- 
lowing information: 

• current weave state: the present aspect definition; 

• previous woven state: the last aspect definition that was woven; 

• a timestamp indicating the last point in time the aspect was woven; 

• a timestamp indicating the last point in time the aspect was modified. 

Weaving on-demand and weave histories are complemented by selective 
weaving (also known as incremental reweaving) which further improves the 
efficiency of the weaving process by only unweaving and reweaving the 
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modified parts of an aspect instead of unweaving and reweaving the whole 
aspect. The input to the weaving process is, therefore, AWeave which is a 
measure of the extent to which an aspect has been modified since the last 
time it was woven. As a result AWeave can range from null (aspect not 
modified since last weave) to current weave state (aspect not woven before 
or completely modified since last weave). 




Fig. 5.12. A weaving process using weave-on-demand, weave histories and selective 
weaving 



The weave-on-demand process checks the LastWoven and LastUpdated 
timestamps when an aspect needs to be woven. If the LastWoven timestamp 
is zero this means that the aspect has never been woven before. The complete 
aspect definition {AWeave — Current Weave State) is passed to the weaving 
process. If the LastWoven timestamp is not zero but newer than the LastUp- 
dated timestamp, this means that the aspect has not been modified since it 
was last woven and hence, does not need to be rewoven. A null weave state 
(AWeave = 0) is passed to the weaving process. If the LastUpdated timestamp 
is newer than the LastWoven timestamp, this means that the aspect has been 
modified since it was last woven. The reweaving process then calculates the 
extent of modification (AWeave = Current Weave State - Previous Woven 
State) and passes this information to the unweaving process which unweaves 
the modified parts before the weaving process reweaves the modified parts. 
Note that the unweaving and weaving processes, in this case, operate under 
the control of the reweaving process which updates the previous woven state 
of the aspect once it has been successfully rewoven. This ensures atomicity 
of the reweave operation. 
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53.2.3 Weaver for the SADES Object Database Evolution System 

The mechanism discussed in Sect. 5. 3.2.2 has been employed to implement 
an aspect weaver as part of the SADES object database evolution system 
(discussed in Chap. 4). SADES has been implemented as a layer on top of 
the Jasmine object database management system (Jasmine 1996) and makes 
extensive use of its proprietary language ODQL to obtain low-level access 
to Jasmine functionality. ODQL is not the only language used in SADES. 
The system, in fact, has been built from a combination of Java, C, C-h-h and 
ODQL. Consequently existing aspect weavers cannot be employed in 
SADES and a custom solution is the only choice. 

The integrated aspect weaver facilitates the implementation of a cost- 
effective, customisable instance adaptation mechanism in SADES. As dis- 
cussed in Sects. 4.2. 1.1 and 4.3.3. 1, the instance adaptation aspects are 
defined using a declarative aspect language modelled on AspectJ. It pro- 
vides three simple constructs facilitating: 

• specification of join points between the aspects and class versions; 

• introduction of new methods into the class versions; 

• redefinition of existing methods in the class versions. 

The maintainer specifies the instance adaptation aspects as declarative 
statements passed as strings to methods in the SADES Java API. The aspect 
specifications are parsed to generate the persistent aspects which are in turn 
associated with the class versions. The persistent representation simply 
stores the aspect code in the database (aspect structure 3 in Sect. 5.3.2. 1). 
This choice is driven by the fact that the instance adaptation code needs to 
be efficient. Hence, code optimisation has been preferred over reflective 
information. 

The aspect weaver fully supports on-demand weaving and maintenance 
of weave histories. Selective weaving is, however, only supported in a lim- 
ited fashion. This is because calculating AWeave is a very complex opera- 
tion and, at present, has only been implemented for specific scenarios. The 
on-demand weaving process is invoked using a composition filters mecha- 
nism and a weaver interface object which exposes the weaver functionality to 
the rest of the system (cf. Sect. 4.3. 3.2). 
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5.4 Applications of Aspect Persistence 

An application of the use of aspect-based querying can be found in (Grundy 
2000b) which describes a component repository supporting aspect-based 
indexing and querying of components. Components can be retrieved for 
reuse on the basis of aspectual services they provide or require. 

Fine-grained storage of aspects and concerns is employed in the Visual 
Separation of Concerns (VSC) system (Chu-Carroll, Wright, et al. 2003). 
Fine-grained program fragments and queries over these fragments are used 
as the basis to formulate multi-dimensional views of the program. Similar 
to the aspect mining support discussed earlier in this chapter, data mining 
and machine learning techniques can be used to identify concerns from the 
fragments. Since the VSC implementation is based on the Stellation soft- 
ware configuration management system (Chu-Carroll, Wright, et al. 2002), 
it is also possible to analyse the development history of the system and make 
inferences about relationships among concerns and whether a change in 
one concern might impact another. 

The aspectual requirements composition and decision support tool, 
ARCADE (Rashid, Moreira, et al. 2003), employs an XML-based require- 
ments description language to specify the viewpoints, aspects and compo- 
sition rules during aspect-oriented requirements engineering. The specifi- 
cations are stored in a native XML database system, eXist (Meier 2003b; 
Meier 2003a). The composition rules can be used as a query mechanism to 
determine how an aspect constrains or influences multiple viewpoints. 
They can also be used to discover conflicts between aspects in order to 
establish trade-offs. 



5.5 Conclusion 

This chapter has focussed on aspect persistence which is a natural extension 
of work on lifetime of aspects. The discussion complements Sect. 4.3 and 
highlights concrete scenarios where aspect persistence is an essential 
requirement. Models for aspect persistence in object-oriented and rela- 
tional databases have been discussed and some concrete implementations 
of these models presented. Two mechanisms for weaving aspects in an 
object database environment: using existing languages and weavers, and 
building custom weavers into the ODBMS have also been presented. Some 
possible persistent structures for aspects when building a weaver into the 
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ODBMS and their advantages and disadvantages have been highlighted. 
Mechanisms such as weave-on-demand, weave histories and selective 
weaving have been proposed to effectively deal with changes to aspect def- 
initions after they have been woven. Selective weaving can significantly 
reduce the reweaving overhead in environments where aspects can live 
beyond compile-time and may be modified after they have been woven. 

The existence of aspect persistence models makes it possible to treat 
aspects as software assets in an asset repository. This opens up the possibil- 
ity of mining the asset repository for existing aspects and adapting them to 
new or slightly different application contexts at lower effort and cost. This, 
in turn, brings exciting possibilities to support variation within software 
systems, particularly software product lines (Clements and Northrop 
2002). Software product lines are concerned with the creation of families of 
products, with each product sharing a common set of features. For 
instance, a common asset in a software product line could be a networking 
module that all the products in the family share. The variation point in this 
instance might be the network protocols which that particular module is 
capable of. The aspect could simply weave in the various networking capa- 
bilities required for the particular software product. The use of aspect 
repositories to support such variations is worth exploring. 

Another interesting point brought to light by the discussion in this chap- 
ter is the need to develop a common persistent aspect representation and 
an infrastructure to serve as middleware between aspect structures in dif- 
ferent AOP approaches and the common persistent representation. 
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Some concerns such as synchronisation (Holmes, Noble, et al. 1998; Clarke 
2000) and tracing (Clarke and Walker 2001a; Kiczales, Hilsdale, et al. 2001) 
are often described as classical candidates for aspectisation in literature on 
AOP. Persistence - the storage and retrieval of application data from sec- 
ondary storage media - is also one such classical example (Mens, Lopes, et 
al. 1997; Suzuki and Yamamoto 1999a). It is advocated that these concerns 
can not only be modularised using AOP techniques, this can be achieved 
with a high degree of reusability for the aspect code. Furthermore, the rest 
of the application can be developed oblivious to the fact that a synchroni- 
sation, tracing or persistence aspect may be composed at a later stage. 

Despite the above claims and widespread use of database management 
systems in today's businesses, there are no real world examples (involving a 
significant number of data classes) available that might demonstrate 
whether: 

• persistence can be effectively modularised using AOP techniques; 

• persistence aspects can be reused; 

• applications can be developed oblivious^ of the persistent nature of the 
data. 

In Chap. 5, models and prototypes for aspect persistence, i.e., storage 
and retrieval of aspects from secondary storage, were discussed. In contrast, 
this chapter considers separating persistence of application data using AOP 
techniques. The aim is to explore whether persistence can be effectively 



1. Obliviousness here means that persistence requirements may be ignored during 
application development. Filman and Friedman (Filman and Friedman 2000) use the 
term obliviousness to indicate that no special hooks are needed in classes operated 
upon by an aspect. This is orthogonal to the use of this term in this chapter. 
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aspectised in a real world application. More specifically, the discussion 
determines whether such aspectisation can be reusable with the application 
and the persistence aspect developed independently of each other. A classi- 
cal database application: a bibliography system and SQL-92 compliant rela- 
tional databases (as the underlying persistence mechanism) are used as the 
basis for the discussion. The application is written in Java with database 
interaction, based on JDBC (Java Database Connectivity), aspectised using 
Aspectjl.06. 

Although the application in this chapter is based on AspectJ and rela- 
tional databases, the reader will also gain some general insight into the suit- 
ability of other AOP techniques in this context and how the emerging per- 
sistence model may be adapted to suit other database technologies, e.g., 
object-oriented databases and object-relational databases. 

In the following. Sect. 6.1 provides an overview of the bibliography 
application used as the basis for this discussion. Section 6.2 describes the 
approach to modularising persistence using aspects. Section 6.3 provides a 
discussion of the lessons learnt from the experience, possible limitations of 
the approach and generalisation to other persistence scenarios. Section 6.4 
discusses some other approaches to aspectise persistence. Section 6.5 con- 
cludes the chapter. 

6.1 A Bibliography Application 

The data model for the bibliography application has been derived from 
information stored on the DBLP server (Ley 2002). However, it has been 
simplified as the example application does not need to maintain links from 
the table of contents to the articles or aggregate individual conferences in a 
series (e.g., the AOSD conferences) into a collection. The latter should not 
be a data model consideration anyway as it is more appropriate to define it 
as a view. The data model is shown in Fig. 6.1 in UML. 

The various association and aggregation relationships in the data model 
have been implemented as aspects. Similarly, aspects have been employed 
in the bibliography user interface classes (developed using the Java Swing 
API) to attach listeners to the various GUI widgets. However, these aspects 
do not have a bearing on the modularisation of persistence. As discussed in 
Sect. 6.2.2, the persistence mechanism employs Java reflection to discover 
the structure of a persistent object. Hence, it is of no consequence, at least 
at a conceptual level, whether the relationship edges are specified within a 
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class or encapsulated in an aspect. It should be noted that, unlike the lis- 
tener aspects, the design of some GUI components does need to take the 
persistent nature of the data into account. These considerations will be dis- 
cussed in the next section. 




Fig. 6.1. Data model of the bibliography application 



6.2 Aspectising Persistence 

This section describes the approach to aspectising database access and the 
rationale behind the various design decisions. It demonstrates that it is pos- 
sible to remain oblivious of the need to store or update the data in the data- 
base during application development. However, components consuming 
the data need to account for both the data source and the nature of its 
retrieval mechanisms. Retrieval can, therefore, only be partially modu- 
larised. Similarly, deletion has to be explicitly triggered by the application. 
The design of the SQL translation aspect is also discussed before moving on 
to describing the general aspect-based persistence framework emerging 
from the bibliography application. 
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6.2.1 Database Access 

There are three important considerations when aspectising database access 
for an application that has been, at least partly, developed without account- 
ing for persistence: 

1. A means to distinguish persistent data from transient data is required. 

2. The aspectised database access functionality should have a high degree of 
reusability. 

3. If the database access is reusable, some customisation points should be 
available to plug-in application requirements such as a specific database 
management system, location of the database and so on. 

In order to distinguish persistent data the concept of a persistent root class 
from object-oriented database systems (Cattell, Barry, et al. 2000) is bor- 
rowed. These systems often require that all classes whose instances are to be 
stored in the database extend a common base class. The base class contains 
some persistence-related functionality and additional functionality is aug- 
mented to the persistent classes by a pre- or post-compilation processor. 
The Persistent Root class in this instance is shown in Fig. 6.2. It only 
encapsulates a very basic yet essential feature: marking an object as deleted. 
This is essential as, due to the automatic garbage collection support in Java, 
transient objects do not have an explicit notion of deletion. Like retrieval, 
deletion can, therefore, not be completely ignored during application 
development. However, it can be simplified by providing this basic func- 
tionality within the PersistentRoot class with the database access func- 
tionality carrying out the actual data removal from the database (this is dis- 
cussed in more detail later). 

public class PersistentRoot { 

protected boolean isDeleted = false; 

public void delete(){ 
this. isDeleted = true; 

} 

public boolean isDeletedC) { 
return thi s . i sDeleted ; 

} 

} 

Fig. 6.2. The persistent root class 
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An application specific aspect can use Aspect] to declare the Persis- 
tentRoot class as the superclass of all classes whose instances are to be 
made persistent^ (cf. Fig. 6.3). 

public aspect ApplicationoatabaseAccess { 

declare parents: (Bibliographyltem || 

AuthorEditor | | 

Publisher || 

Publ i sherLocation) 
extends PersistentRoot ; 

// other code 

} 

Fig. 6.3. An aspect declaring PersistentRoot as the superclass of classes with persis- 
tent instances 

The PersistentRoot class also plays a fundamental role in aspectising 
database access in a highly reusable fashion. While the DatabaseAccess 
aspect in Fig. 6.4 employs the notion of abstract aspects and pointcuts from 
Aspect], the high degree of reusability is derived from the ability to define 
join points with reference to a common, application independent point: the 
PersistentRoot class. This makes it possible to reuse the Database- 
Access aspect in another application whose data classes have been declared 
as subclasses of the PersistentRoot class (either by means of an aspect or 
by using the standard ]ava inheritance mechanisms). 



2. Note that the potential subclasses must inherit from Object as Persistent-Root 
does. 
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public abstract aspect DatabaseAccess { 



/private static Connection dbConnection ; 
private static String dbURL; 



(3 



abstract pointcut establishConnectionO ; 
abstract pointcut closeConnectionO ; 



public abstract string getDatabaseURL() ; 
public abstract string getDri verNameO ; 

/pointcut trapinstantiationsO : cal 1 (Persi stentRoot+ . new( . . ; 




pointcut trapupdates (Persi stentRoot obj): 

!cflow(call (public static vector 

SQLTranslation.getobjects(ResultSet , string))) && 
(this(obj) && 

execution(public void PersistentRoot+.set*(. .)) 



I 




pointcut trapRetrievals( ): 

call (Vector Persi stentData.get*( . .)) ; 

public static Persi stentData getPersi stentDataO { ... } 



I pointcut trapDeletes (Persi StentRoot obj): this (obj) && 

execution(public void Persi stentRoot+. del ete()) ; 



& 



pointcut detectDeletedObjects(Persi StentRoot obj): this(obj) && 
(execution(public * Persi stentRoot+.get*(. .)) II 
execution(public * PersistentRoot+.set*(. .)) I I 
execution(public String Persi stentRoot+. toStri ngO) 
); 



f protected 






protected 



static integer update(Stri ng sql Statement) 

throws SQLException { ... } 

static Vector retrieve(String sql Statement , String className) 

throws SQLException { ... } 



protected static Object transactionwrapper(Stri ng methodName, 

Object [] params) { ... } 




public static aspect MetaDataAccess { ... } 



// advice code 

} 



Fig. 6.4. The key features of the DatabaseAccess aspect 



Let us look at the various key features of the DatabaseAccess aspect 
labelled in Fig. 6.4 in more detail. 



6.2.1 .1 Connection 

The ability to connect and disconnect from the database is a basic feature 
for a persistent application. However, as mentioned earlier, reusability 
requirements dictate that such functionality is generic with the availability 
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of specific customisation points to incorporate application specific require- 
ments such as: 

• the location of the database; 

• the database management system and/or driver to be used; 

• points in the application control flow where a database connection 

should be established or closed. 

In the DatabaseAccess aspect the above needs are addressed through 
the use of two abstract pointcuts and two abstract methods (cf. label (A) in 
Fig. 6.4). The two abstract methods are invoked byabefore advice, oper- 
ating on the abstract pointcut establishConnect1on,to obtain informa- 
tion to connect to the database (the two static variables are used to hold the 
connection information). The database URL and driver details are supplied 
by an application aspect extending the DatabaseAccess aspect and con- 
cretising the two methods. Such an aspect also concretises the two abstract 
pointcuts to specify the join points in the application control flow where 
database connections are to be established or closed. For this implementa- 
tion the Appl 1 cati on Data base Access aspect in Fig. 6.3 has been used for 
the purpose. Note that no connection pooling has been implemented. This 
can, however, easily be incorporated into the DatabaseAccess aspect with 
localised impact. 

Note that there are a number of JDBC drivers available. These range 
from pure Java drivers to those that act as a bridge to an underlying ODBC 
(Open Database Connectivity) driver. The various features in the JDBC 
API, particularly those pertaining to database meta-data access, are not 
fully supported by all drivers. Consequently, to have a high degree of port- 
ability across drivers, the implementation of the DatabaseAccess aspect is 
based on the basic Sun Microsystems JDBC-ODBC Bridge Driver which, to 
the best of the author's knowledge, offers the lowest common denominator 
in terms of supported functionality. While this provides the flexibility of 
choosing a different driver and/or a database management system for the 
bibliography system in the future, most advanced features of a new driver 
would not be exploited without modifying the aspect code (though the 
change will be localised to the aspect). This reflects that, like most other 
programming approaches, such a trade-off needs to be considered when 
designing reusable aspects. 
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6.2.1 .2 Storage and Update 

The two pointcuts (cf. label (B) in Fig. 6.4), respectively, identify the join 
points where an object should be stored in the database or its persistent rep- 
resentation updated. An object should be stored in the database as soon as 
it is instantiated (cf. the t r a p I n s t a n 1 1 a 1 1 o n s pointcut in Fig. 6.4) . How- 
ever, two factors need to be considered when aspectising this functionality: 

1. Once an object is stored in the database all objects reachable from it 
should also be made persistent. This is in line with the well-known per- 
sistence by reachability requirement for object persistence (Elmasri and 
Navathe 2000) and ensures that the object and all its references can be 
appropriately re-established upon retrieval. Due to the underlying rela- 
tional model, the objects are written to the database through translation 
to SQL insert statements. The enforcement of reachability semantics 
is, therefore, left to the SQLT ransl ati on aspect (cf. Sect. 6.2.2). 

2. The object can only be stored in the database after its constructor has 
been executed. Naturally, an after returning advice is employed. 
However, in case of transaction rollback, the transient instantiation of 
the object is not automatically aborted. So, once the underlying t r a n s - 
actionWrapper (discussed later) signals a rollback, the after advice 
must ensure that either an exception is raised or the transient copy is 
marked deleted (by invoking the del ete( ) method on the object) so 
that it maybe detected as unusable (cf. pointcut in block labelled (D) in 
Fig. 6.4). However, any exception has to be wrapped as an Aspect} Sof - 
tException because a Java throws clause is not currently supported for 
advices (with the exception of the around advice). It is essential that 
AOP techniques treat advices as first class entities in order to clarify the 
signature of the behaviour specified within an aspect. Since one can 
already supply arguments to advices in Aspect} in the same fashion as 
Java methods, it is only natural that features such as declaration of excep- 
tions thrown from the advice code should be incorporated and more 
reflective access supported. As discussed later, such reflective access is 
fundamental in the development of reusable aspects. 

The update mechanism relies on trapping all invocations of setter meth- 
ods for persistent objects. However, if such invocations happen within the 
control flow of the getObjects method in the SQLTransl ati on aspect 
they are ignored. This method is used to rebuild the objects from their rela- 
tional representation (which might span multiple tables due to the normal- 
isation constraints in the relational model). Setter method calls in its control 
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flow, therefore, are used to populate an empty copy of the object and hence, 
do not have update semantics from a persistence perspective. A before 
advice is employed to ensure that the database state is updated prior to the 
transient object being modified. This makes it possible to abort the transient 
update (in a fashion similar to that described for instantiation) if a transac- 
tion is rolled back. Also, note that an intentional decision has been taken to 
rely on strict encapsulation for access to member variables of persistent 
objects, i.e., only setter and getter methods can be used and no direct public 
access otherwise is allowed. Such good practice should be enforced for all 
persistent applications as it ensures that the interface of the class is not often 
modified due to changes to internal representation of member variables. 
However, if required, only the trapUpdates pointcut definition needs to be 
modified to trap direct updates to member variables. 

The trapinstanti ati ons and trapUpdates pointcuts do not require 
any special preparation on part of the application code instantiating the 
classes in Fig. 6. 1 or calling the setter methods on their instances. The devel- 
oper can, therefore, remain oblivious to the fact the advices referring to 
these pointcuts will store the objects in the database or update their persis- 
tent representations. 

6.2.1. 3 Retrieval 

Unlike storage and update, it is virtually impossible to remain oblivious of 
the persistent nature of the data during retrieval. The term “retrieval” 
means: 

“to get and bring back; especially: to recover (as information) from storage” 
(Merriam-Webster 2002). 

The application, therefore, cannot ignore the fact that the persistent 
objects (in this case instances of the classes in Fig. 6.1) or the references to 
these are obtained from an external source. This is further compounded by 
the declarative nature of retrieval mechanisms in database systems which 
retrieve data based on predicates or selection conditions. Query languages 
remain the dominant retrieval mechanism. Although in object-oriented 
databases retrieval is possible through traversal, the Object Query Language 
(OQL) forms part of the ODMG standard (Cattell, Barry, et al. 2000) and 
either its implementation or a proprietary query language is supported by 
most commercial systems, e.g., (Jasmine 1996; ObjectStore 1996; POET 
1997; 02 1998). Similarly, the Java Data Objects (JDO) specification (Roos 
2002) also supports a query language. 
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Despite the above observation, aspects can play an important role in 
modularising parts of the retrieval related code. In case of the bibliography 
application this is achieved through a special interface called Persistent- 
Data which offers a number of methods to be implemented by a class. The 
methods expose functionality such as retrieving the extent, i.e., the set of all 
objects of a class or specific objects of a class based on a selection condition. 
All these methods return a Vector containing the objects retrieved. The 
getPersi stentData ( ) method in the DatabaseAccess aspect (cf. label 
(C) in Fig. 6.4) provides a reference to an instance of a class implementing 
this interface. An application can obtain this reference and use it as the basis 
of any retrieval-related code. 

The class implementing the Persi stentData interface is used to pro- 
vide hooks that are used by the trapRetrievals pointcut (cf. label (C) in 
Fig. 6.4) to identify the points at which the application attempts to retrieve 
the data. Note that this class is not application-specific and is a reusable, 
support mechanism for the DatabaseAccess aspect. An around advice for 
the trapRetrievals pointcut employs the AspectJ reflection API to 
obtain the various selection conditions passed as arguments to the hook 
methods. With the help of the SQLTranslation aspect it retrieves the 
objects and returns the resulting Vector to the application. 

The modularisation approach described above provides a high degree of 
reusability for the retrieval code as it remains application independent. 
Although the application cannot remain unconcerned with retrieval, this is 
a positive conclusion. This is because retrieval is often an important archi- 
tectural consideration in the design of data consumer components. The 
amount of data that will be available as a result of retrieval can, for instance, 
be a significant factor in the design of user interface components. Several of 
these user interface design considerations are encountered in the bibliogra- 
phy application. For instance, the application supports the user to relate an 
author already existing in the database to a new item being added. This is 
done by providing a list of existing authors when entering the new item 
details. Since the bibliography database contains thousands of authors, it is 
a very expensive operation to retrieve all the authors particularly when the 
user might not choose an existing author. Even if the user were to choose 
one or more existing author, the operation remains expensive as only a few 
authors will be selected. It, therefore, makes sense to provide the user with 
some mechanism to navigate through a set of lists containing subsets of 
authors (possibly based on alphabetical ordering) and retrieving (on 
demand) only the subsets of authors the user might be interested in. 
Retrieval considerations in this case make it possible to not only optimise 




6.2 Aspectising Persistence 129 



the database operations but also provide a user interface presenting a large 
amount of data to the user in a manageable fashion. 

6.2.1. 4 Deletion 

Like retrieval, deletion of persistent data has to be explicitly considered dur- 
ing application development and cannot be fully aspectised. This is because 
data has to be deleted from the data source upon specific request from the 
application. In addition, there are implementation specific factors. Due to 
the automatic garbage collection, there is no notion of explicitly deleting an 
object in Java. Consequently, there is no reference point available for the 
DatabaseAccess aspect to remove the persistent representation of an 
object from the database. In a language such as C++, the invocation of the 
delete operator can be trapped (using an aspect language) and the object 
removed from the database. Still one cannot be sure if the application actu- 
ally intended to remove the object from disk or merely from the memory. 
It is, therefore, good practice to explicitly delete persistent objects hence, 
providing a non-fuzzy point of reference on which the aspect can operate. 

In case of the bibliography application this reference point is provided by 
the delete() method in the Persi stentRoot class (cf. Fig. 6.2). The 
application invokes this method for the persistent instances (their classes 
are declared as sub-classes of the Persi stentRoot class as shown in Fig. 
6.3). The trapDeletes() pointcut (cf. label (D) in Fig. 6.4) captures these 
invocations and a before advice, for reasons similar to update, translates 
the request to SQL using the SQLTranslation aspect and removes the per- 
sistent representation of the object. It also marks the object for early collec- 
tion by using the garbage collector interaction features in the java. 

I ang . ref package. The detectDel etedObjects pointcut (cf. label (D) in 
Fig. 6.4) and its associated before advice complements the above function- 
ality by throwing an exception (wrapped as an Aspect! SoftException) 
whenever a piece of code attempts to access the transient representation of 
a deleted persistent object that has not yet been collected by the garbage 
collector. 

The use of the del ete ( ) method in the Persi stentRoot class as a ref- 
erence point makes it possible to keep the deletion functionality reusable 
and application independent. Flowever, the application programmer 
should be aware of the existence of the Persi stentRoot class, its public 
interface and that it will eventually be declared as a superclass of all classes 
whose instances are to be stored in the database. This is essential as other- 
wise the application programmer will be calling a method that to him/her 
is unspecified and such a practice can lead to inconsistencies in the code. 
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The application programmer does not need to be aware of the existence of 
the deletion functionality in the DatabaseAccess aspect or the SQL- 
Transl ati on aspect. 

6.2.1. 5 Transactions 

The three methods: update, retrieve and t ransacti onWrapper (cf 

label (E) in Fig. 6.4) together encapsulate the transaction functionality. This 
is because, although JDBC has an explicit (optional) notion of transaction 
commit and rollback, transactions are always implicitly started. The update 
and retrieve methods encapsulate the code that results in the start of read- 
write and read-only transactions respectively. Naturally the update method 
caters for operations that change the state of the database, i.e., SQL insert, 
update and delete statements while the r e t r i e v e method supports que- 
rying operations on the database. The sql Statement argument in both 
methods is obtained by the appropriate advice code through the SQLTrans- 
1 ati on aspect. The className argument in the retrieve method is 
obtained reflectively by the advice operating on the trapRetrievals 
pointcut. Class name is an argument for all the methods in the Persi s - 
tentData interface as it is required to establish the mapping between the 
object structure and the underlying relational schema (cf. Sect. 6.2.2). 

The various advices within the DatabaseAccess aspect do not directly 
invoke the u p d a t e or the r e t r i e v e method. Instead they pass the name of 
the method to be invoked together with an array of arguments to the 
transacti onWrapper method (cf. Fig. 6.5). This helps to modularise the 
nested try-catch blocks as otherwise these have to be repeated in individual 
advice code. The outer try-catch block is responsible for catching any SQL 
exceptions (thrown by JDBC) during the invocation of the commit and 
rollback methods. The inner try-catch-finally block in the trans- 
acti onWrapper method reflectively invokes the required method. It uses a 
mechanism similar to that presented in (Kienzle and Guerraoui 2002), i.e., 
a boolean variable to decide whether to commit the transaction or rollback. 
Note that a transaction is aborted when any exception is thrown regardless 
of whether it arises from reflective access or the database operation. This 
safer option has been chosen intentionally as reflective operations play a 
fundamental role during translation to/from SQL. Consequently, it is 
highly likely that any exception directly or indirectly relates to database 
access. Furthermore, all database access functionality, though at times not 
oblivious, is aspectised. Therefore, the application does not need to signal 
exceptions to abort transactions as these are signalled by the aspecitsation 
infrastructure: JDBC, the Java reflection API or the SQLTranslation 
aspect. A null value returned to the invoking advice implies an unsuccessful 
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transaction prompting it to execute transient rollback and signal an excep- 
tion (wrapped as an Aspect} Soft Except 1 on). 

Unlike (Kienzle and Guerraoui 2002) where an around advice is 
employed for transaction wrapping, the transact lonWrapper is explicitly 
invoked from the advice code dealing with storage, update, removal and 
retrieval of persistent objects. As a result, the transact ionWrapper is trig- 
gered strictly for database operations and no unnecessary wrapping over- 
heads exist for transient operations. In this case the fact that the transac- 
tions do not operate in a pure OO environment benefits the aspect design. 
For database operations reflection, of course, adds some overhead to the 
transaction. However, some locking optimisation is provided by the 
update and retrieve methods which establish the appropriate read-write 
and read-only locks respectively. 



protected static Object transactionwrapper(Stri ng methodName , 

Object [] params) { 



try { 

boolean commi table = true; 

Object obj = null; 

try { 

Class thisclass = Class.forNameC'DatabaseAccess") ; 
Method [] methods = thi sclass .getoeclaredMethodsO ; 
Method theMethod = null; 
for (int i=0; i<methods. length; i++) { 

if (methods[i] .getNameO .equals (methodName)) 
theMethod = methods [i]; 

} 

obj = theMethod. i nvoke (nul 1 , params); 

} 

catch (Exception e) { 

System . out . pri ntl n (e . tost ri ng () ) ; 
dbConnecti on . rol 1 back() ; 
commi table = false; 

} 

finally { 

if (commi table) 

dbConnecti on . commi t() ; 
return obj ; 

} 

} 

catch (SQLExcepti on e) { 

System, out. pri ntl nC'Error in committing or 

rolling back: " + e . tostri ngO) ; 

return nul 1 ; 

} 

} 

Fig. 6.5. The transaction wrapper method 
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6.2.1. 6 Meta-data Access 

This static inner aspect (cf. label (F) in Fig. 6.4) encapsulates helper func- 
tionality to access the database meta-data such as the column names in a 
relational table or its foreign key links. This functionality is required by the 
SQLTransl ati on aspect. The MetaDataAccess aspect, therefore, serves 
two purposes: 

1. It avoids unnecessary duplication of JDBC meta-data calls during SQL 
translation. For example, one of the features encapsulated by the aspect 
is obtaining a JDBC Resul tSet object containing the column names for 
a table and returning them as an E n u m e r a 1 1 o n for ease of traversal dur- 
ing SQL translation. 

2. If a desired meta-data access feature is not supported by the underlying 
database driver, it can be built on top of more primitive features available. 
An update can then be carried out without affecting the SQL translation 
functionality once a newer version of the driver or a better driver becomes 
available. 

Note that meta-data access functionality should be viewed as a subset of 
the overall database access functionality. Its modularisation as an inner 
aspect of the DatabaseAccess aspect, therefore, provides a more natural 
separation of concerns than it being encapsulated in a sub-aspect. This 
argument is further strengthened by the observation that, in the Meta- 
DataAccess aspect, there is no need to concretise or override any features 
of the DatabaseAccess aspect. 



6.2.2 SQL Translation 

SQL translation must be considered as a separate concern when aspecitising 
persistence of OO data using relational databases. This is because database 
access (and in general persistent storage access) is a concern for any appli- 
cation involving persistent data. Flowever, it is not necessary that any trans- 
lation to the underlying data model will be required, e.g., if an object-ori- 
ented database is being used. When an OO application employs a relational 
database as a persistent store, there is a need to flatten the object structure 
to a relational model due to the lack of support for complex data types in 
the latter. Fig. 6.6 shows part of the relational database structure for the bib- 
liography application. The Article objects are mapped to two tables, one 
capturing the attributes defined in the superclass Bibliographyltem 
while the other containing those defined within the Arti cl e class itself. 
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The inheritance relationship is captured by a simple one-to-one relation- 
ship (for each Article object there can be only one row in each table). The 
many-to-many relationship between bibliography items and authors/edi- 
tors is captured in a separate relational table (this is a defacto mechanism 
for capturing many-to-many relationships). 

There is a need for an intermediate mechanism to provide the object-to- 
relational mapping and SQL translation provides a standard-based 
approach for the purpose. One might argue that, for update and deletion 
purposes, JDBC Resul tSet objects maybe employed to modify the data- 
base instead. However, not all JDBC drivers support use of bi-directional 
cursors on result sets. This is an essential feature to search for records per- 
taining to an object within a Resul tSet. Also, this requires retrieving the 
object into a ResultSet and applying the update which results in unnec- 
essary disk access. The S Q L D a t a interface in JDBC, on the other hand, only 
supports mapping to/from user-defined SQL types in an object-relational 
model and, hence, cannot be employed for pure relational databases. 




Fig. 6.6. Part of the OO data model mapped to the relational model 

If an SQL translation mechanism is to be reusable, it must be highly 
independent of any application-specific mapping. Such mapping can then 
be specified when the aspectised persistence mechanism is composed with 
the application. In case of the bibliography application, a singleton lookup 
table is used to establish the mapping. The use of the lookup table is mini- 
mised by only maintaining mapping at a coarse-granularity, i.e., the tables 
to which objects of a class and many-to-many relationships map. Mapping 
of individual object attributes onto relational table columns is not main- 
tained in the lookup table and is instead achieved through the use of iden- 
tical names. However, if different naming schemes are being used, the map- 
ping can be contained within the lookup table. The mapping in the lookup 
table is specified through the Establ i shMappi ng aspect (cf. Fig. 6.7) 
which sets up the mapping before the connection with the database is 
established (cf. label (B) in Fig. 6.7). An AuthorEdi tor object maps onto 
the AuthorEdi tor table (cf. label (C) in Fig. 6.7), an Art 1 cl e object maps 
onto the B1 bl 1 ography Item and Arti cl e tables (cf. label (D) in Fig. 6.7) 
while the many-to-many authorsOrEditors relationship maps onto the 
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I temAuthoredOrEdi ted table (cf. label (E) in Fig. 6.7). Note that the 
EstablishMapping aspect must dominate (have higher execution priority 
than) the DatabaseAccess aspect (cf. label (A) in Fig. 6.7) to ensure that 
the mapping is established before connecting to the database. 

The main features of the SQLTransl ati on aspect are shown in Fig. 6.8. 
The sql Execution pointcut captures the fact that an object might map to 
multiple tables and hence, result in translation to multiple SQL statements. 
An a round advice tests if a single SQL statement is being executed through 
the JDBC Statement object in which case the normal execution in the 
DatabaseAccess aspect proceeds. On the other hand, if multiple SQL 
statements are found, execution is carried out in batch mode (JDBC has spe- 
cific support for the purpose). Note that mapping to multiple SQL state- 
ments is an SQL translation concern and hence, the pointcut dealing with 
this must form part of the corresponding aspect. Although the sql Execu - 
t1 on pointcut captures Statement . executeUpdateC Stri ng ) calls from 
a single method (the update method) in the DatabaseAccess aspect, it 
makes it possible to separate an essential piece of SQL translation function- 
ality and incorporate it within theSQLTranslation aspect. Its use is, there- 
fore, not out of step with good aspect-oriented programming practices. 



©[ public aspect EstablishMapping dominates DatabaseAccess { 
pointcut setupMappingO : 

Appl i cati onDatabaseAccess . establ i shconnecti on () ; 
beforeO: setupMappingO { 




LookupTable mappingTable = LookupTable.getLookupTableO ; 

mappi ngTab! e .created assToTabI eMappi ngC'AuthorEdi tor” , 

"AuthorEdi tor”) ; 



mappi ngrabl e .created assToTabI eMappi ngC'Arti cl e” , 

"Bibliographyltem”) ; 

mappi ngrabl e .created assroTabl eMappi ngC'Arti cl e” , 

"Article”) ; 




mappi ngrabl e . createRel ati onshi prorabl eMappi ng ( 

"authorsOrEdi tors” , 
"itemAuthoredEdited”) ; 



} 



} 

Fig. 6.7. Aspect used to specify the object-to-relational mapping 
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The various getXXXSQL methods and the getObjects method employ 
Java reflection and the mapping information in the lookup table to map the 
objects, their updates and deletion to the database and recreate the objects 
upon retrieval. Since strict encapsulation is imposed, the object attributes 
corresponding to the relational table columns are identified by recursively 
obtaining the declared members and not just the public ones. If propaga- 
tion of updates for linked tables is supported in the underlying database 
design, this feature is exploited otherwise the linked tables are individually 
updated, but within a single transaction boundary to ensure consistency. 
Note that the use of reflection for object-to-relational mapping results in 
some additional overhead during database interaction. As pointed out in 
(Parsons, Rashid, et al. 1999), such trade-offs have to be made when design- 
ing highly flexible components such as the SQLTranslation aspect. 

public aspect SQLTranslation { 

pointcut sql Execution(Statement statement, 

String sql Statement) : 
target(statement) && 
call (public int 

Statement . executeupdate (St ri ng) ) && 
args(sql Statement) ; 

// around advice for sql Execution pointcut 

public static String getlnsertionSQL(Persi stentRoot obj); 

public static String getUpdateSQL(Persi stentRoot obj, 

String methodName, 
object arg) ; 

public static String getDeleteSQL(Persi stentRoot obj); 

public static String getQuerySQL(Stri ng className, 

String selectionCondi tion) ; 

public static vector getObjects (ResultSet rs. 

String className); 

// helper methods 

} 

Fig. 6.8. The main features of the SQLTranslation aspect 
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6.2.3 The Emerging Persistence Framework 

Based on the discussion in Sects. 6.2.1 and 6.2.2 one can observe a general 
aspect-based persistence framework emerging. This framework is shown in 
UML in Fig. 6.9. Members have been omitted from the classes, aspects and 
the interface for simplicity. The framework challenges one of the widely 
misunderstood promises of AOP. It is often assumed that an aspect implies 
a large piece of code modularised by a single AspectJ-like aspect construct. 
This is not true but for the simplest of cases. As shown in Fig. 6.9, aspecti- 
sation requires that a coherent set of modules including classes and aspects 
collaborate to modularise a crosscutting concern. Such a view of AOP also 
ensures that aspectisation is not forced and in fact leads to a natural separa- 
tion of concern, e.g., the separation of the DatabaseAccess and SQL- 
Translation aspects in this persistence framework. Furthermore, it makes 
it possible to draw upon established best practices and guidelines from the 
frameworks community, as has been the case for flexibility trade-offs in our 
aspectisation. 




Fig. 6.9. The persistence framework emerging from the application 
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63 Analysis of the Persistence Aspectisation 

Let us now discuss the lessons that can be learnt from the persistence frame- 
work in Sect. 6.2 and how it may be adapted to other persistence mecha- 
nisms and AOP techniques. 



6.3.1 Using Other Persistence Mechanisms 

The persistence framework shown in Fig. 6.9 has emerged from a classical 
relational database application. It can, therefore, be reused in any other OO 
application employing an SQL-92 compliant relational database. For 
object-relational databases employing SQL-3, the framework implementa- 
tion should still be reusable. However, the SQL translation mechanism will 
need to be enhanced to cater for the user-defined types in SQL-3. One 
option is to exploit the SQ LDa t a interface in JDBC which provides support 
for such mapping. As far as object-oriented databases are concerned the 
framework will need to be re-implemented. However, the persistence 
model used by the framework can still be exploited. The various pointcuts 
in the DatabaseAccess aspect will be required as these are the points in the 
application control flow where persistence features are composed regard- 
less of the nature of the persistence mechanism. Similarly, a transaction 
wrapper will be needed and aPersistentData interface to support declar- 
ative access from the application. Of course, the SQL translation infrastruc- 
ture (the SQLT ransl ati on aspect, lookup table and Establ i shMappi ng 
aspect) will not be required as there will be no data model mismatch 
between the OO application and the database. The MetaDataAccess 
aspect will not be needed either as it is only needed to support SQL transla- 
tion. The Persistent Root class will be required to act as a surrogate 
inheriting from the object database system’s root class which cannot be 
modified due to proprietary restrictions. This approach has worked suc- 
cessfully when designing aspect persistence mechanisms (cf. Sect. 5.2.1). 



6.3.2 Reflection and Other AOP Techniques 

In the persistence framework emerging from the bibliography application, 
reflection has played a fundamental role in the design of a reusable transac- 
tion wrapper and, more importantly, SQL translation mechanism. Not 
only the Java reflection API but also the Aspect J reflection API has been 
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exploited for the purpose. Aspect} pointcuts are mainly used to register 
points of interest in the application or persistence framework control flow. 
Genericity is provided by the use of reflection whenever application specific 
code would be required otherwise. This strengthens the argument for a 
hybrid approach to separation of crosscutting concerns (Rashid 2001c). It 
also implies that if the resulting persistence framework were to be imple- 
mented in another language environment, both the base language and the 
aspect language would need to support reflection. 

While the use of reflection during aspectisation has led to the emergence 
of a generic, reusable framework it has certain drawbacks as well. Most of 
these relate to the SQL translation. For instance, the SQL translation mech- 
anism makes the well-defined assumption that strict encapsulation is 
enforced and only getter and setter methods will be used to provide public 
access to an object’s state. However, programmers might choose to ignore 
this assumption or simply might forget to include appropriate getter/setter 
methods. This will result in the translation mechanism becoming inopera- 
tive as methods are discovered dynamically and static checks cannot be 
applied. This risk can be reduced by providing support for generating getter 
and setter methods. Alternatively, the Aspect} declare error feature can 
be used to force programmers to define these methods. 

Reflective invocation, of course, has its performance penalties. These can 
be counter-balanced by the use of a cache. In fact, a cache becomes an 
essential concern as the size of the database grows. The various pointcuts 
and, the update and retrieve methods within the DatabaseAccess 
aspect provide excellent reference points for plugging a cache into the per- 
sistence framework. However, the introduction of a cache should only be 
considered for applications with a large database as it is likely to result in 
unnecessary overheads otherwise. The nature of the application must also 
be taken into account, e.g., whether it is necessary to optimise retrieval (due 
to frequent querying and infrequent updates as is the case for the bibliogra- 
phy application) or updates or both. 

The AOP model in Aspect} is well suited for aspectising persistence. This 
is because persistence is a general concern regardless of the individual state 
of an object. Therefore, the extent-oriented nature of Aspect} pointcuts and 
advices is very useful in this context. Relationships, on the other hand, are 
an entirely different matter. In the bibliography application these have been 
implemented as aspects mainly relying on Aspect} introductions. As men- 
tioned earlier conceptually this should be of no consequence. This is, unfor- 
tunately, not the case and the use of introductions introduces additional 
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overhead during SQL translation as the reflectively obtained attributes of 
an object have to be tested to check whether they are collections. If so the 
information in the lookup table is used to establish if a collection represents 
an edge of the relationship. This is further complicated by the fact that the 
Aspect! weaver renames the introduced edges to avoid conflicts. When 
reflectively accessed the name of the relationship is different from what has 
been specified in the mapping. The translation mechanism, therefore, 
requires knowledge of the renaming scheme making it susceptible to break- 
down as the language and its weaver evolve. Based on experience with rela- 
tionships in the bibliography application, it can be concluded that intro- 
ductions must be used with great caution especially if their use results in 
loss of semantic information. In case of relationships in the bibliography 
application a well-defined relationship model such as the one described in 
Sect. 4.3.1 with relationship aspects attached on a per-instance basis using 
composition filters would have been more suitable. This, in turn, indicates 
the need for environments that allow multiple AOP techniques and plat- 
forms to co-exist hence allowing the use of the most appropriate technique 
for modularising a particular crosscutting concern. 



6.3.3 Aspect Interaction 

The dominates construct in Aspect! has been sufficient to resolve the sim- 
ple interaction between the Establ 1 shMappI ng and DatabaseAccess 
aspects. However, if a cache is plugged in, the interactions are expected to 
become more complex as the advices in the caching aspect will operate with 
reference to the same pointcuts as in the DatabaseAccess aspect. Further- 
more, several aspects are often composed only for development purposes 
and can introduce more interactions. For example, during the development 
of the bibliography application a T r a c 1 n g aspect was employed for debug- 
ging purposes. Another aspect used was the Extent aspect which main- 
tained transient extents for persistent classes to allow testing of the storage 
and update features without having to design the retrieval mechanism. The 
two testing aspects interacted with the advices in the DatabaseAccess 
aspect. However, the domination relationship among the three aspects was 
highly dynamic. For example, at times it was desirable to start displaying 
tracing information before the advice performing a database operation 
while at other times it was required to begin tracing output afterwards. Sim- 
ilarly, sometimes the Extent aspect was required to be compiled-in and 
vice versa. This required a lot of changes to the dominates relationship 
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among these aspects. It became quite clear that, even for a system with few 
aspects and classes, such an interaction resolution model could be error- 
prone and cumbersome. Since interactions cut across aspects in a system, it 
is essential that AOP techniques in general (and not just Aspectl) offer sig- 
nificant support for the detection, modularisation and resolution of inter- 
actions. This support will play a fundamental role in the testing and verifi- 
cation of aspect-oriented applications and hence, act as a critical factor in 
large-scale adoption of aspect-orientation. 



6.4 Other Approaches Aspectising Persistence and 
Related Concerns 

Kienzle and Guerraoui (Kienzle and Guerraoui 2002) present an analysis of 
using Aspectl for separating transactions based on the OPTIMA framework 
(Kienzle 2001). They argue that using an Aspectl around advice to wrap 
transactions around transactional methods is inefficient due to lack of lock- 
ing optimisations. They also discuss the dangers of using exceptions to sig- 
nal transaction abortion in a multi-threaded, distributed environment. 
They conclude that transactions should be part of the phenomenon simu- 
lated by objects. The aim of the case study is to investigate aspectisation of 
transactions which are only one facet of persistence. Modularisation of 
code dealing with storage and retrieval of application data from persistent 
storage is not dealt with in detail. Furthermore, the transactions considered 
operate in a pure object-oriented environment. This is seldom the case for 
database applications as relational databases claim almost 80% of the mar- 
ket share. 

Transactions have also been considered during the aspectisation of per- 
sistence in the bibliography application discussed in this chapter. However, 
the IDBC transaction model is much simpler than OPTIMA and fewer fac- 
tors need to be considered for providing an optimal transaction mecha- 
nism. Firstly, due to the implicit start of transactions in IDBC, the t r a n s - 
actionWrapperis explicitly invoked from advices manipulating persistent 
data. Consequently, although transactions are not part of the application 
phenomenon, the code dealing with persistent objects (in the Database- 
Access aspect) is not unaware of the existence of transaction boundaries. 
This also means that transactions are only wrapped around operations that 
result in database access hence, avoiding unnecessary overheads. Moreover, 
the existence of the u p d a t e and retrieve methods reflectively invoked by 
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the transaction wrapper provides some degree of locking optimisation. The 
advices in the DatabaseAccess aspect also use exceptions (wrapped as an 
Aspect! SoftException) to indicate aborted transactions. Handling of 
such exceptions should be a concern for the integration stage within the 
application development process and can be dealt with by exception han- 
dling aspects as in (Soares, Laureano, et al. 2002). 

Soares et al. (Soares, Laureano, et al. 2002) describe their experiences 
with Aspect! as a means for refactoring distribution and persistence con- 
cerns in a layered web-based information system. The data model for this 
application is much simpler than the bibliography application and the 
focus of the work is on refactoring an existing application and not exploring 
application development independent of persistence requirements or 
development of a reusable persistence aspect. Furthermore, most of their 
persistence aspects are application specific and highly reliant on the layered 
architecture. The persistence framework emerging from the bibliography 
application in this chapter is not bound to a particular architecture and can 
be reused directly in any relational database application. Soares et al. widely 
employ interfaces to limit the dependence of aspects on the signatures of 
the methods (implemented in specific classes) that the aspects advise. 
While this may be a convenient way of aspect - class decoupling, it has also 
led to code duplication within interfaces as is the case for the hierarchy of 
transactional interfaces provided for locking optimisation. Moreover, these 
transactional interfaces are application specific and also result in duplica- 
tion of code within the transaction aspect. In the persistence framework 
described in this chapter, only a single interface with application-indepen- 
dent methods is employed in order to expose retrieval functionality to the 
application. The locking optimisations are generic and, due to the reflective 
transaction wrapper, new optimisations can be introduced without dupli- 
cation of transactional code. 

A generic persistence aspect has also been implemented within !AC 
(Pawlak, Seinturier, et al. 2001): a framework for dynamic aspect-oriented 
programming in !ava. Like (Soares, Laureano, et al. 2002) the architecture 
used for this aspectisation is also based on the existence of an additional 
layer between the persistent storage and !AC. No large applications (com- 
parable to the bibliography application in this chapter) using the !AC per- 
sistence aspect are yet available. 

Neither !AC nor Soares et al. have considered issues of data normalisa- 
tion while mapping objects to relational databases. As discussed earlier in 
this chapter, normalisation brings a new level of complexity to persistence 
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modelling with additional considerations such as mapping and retrieving 
an object from multiple tables. Furthermore, both of the above approaches 
have not identified SQL generation as a crosscutting concern. This has 
resulted in SQL statements being spread throughout components support- 
ing the persistence aspect implementation. In (Soares, Laureano, et al. 
2002) application-specific SQL statements have been hard-coded into the 
persistence code. Any changes to the database structure will, therefore, 
result in a ripple effect on a large portion of the persistence code. 

(Kiselev 2002) describes a simple database application where aspects are 
employed for authentication, exception handling, caching, pooling and so 
on. Storage and retrieval of application data has not been aspectised and 
SQL statements are hard-coded. 



6.5 Conclusion 

This chapter has discussed aspectisation of persistence in a classical data- 
base application: a bibliography system. The general aim was to explore 
whether AOP techniques offer an effective means to modularise persistence 
in a real world application scenario. The discussion in the chapter demon- 
strates that the answer is indeed “y^s”. However, like all other pieces of soft- 
ware, the designers of aspects also need to consider a number of software 
engineering factors. Firstly, trade-offs between genericity and performance 
need to be made. In the aspectisation, one could have hard-coded the appli- 
cation-specific SQL statements in the SQLTranslation aspect instead of 
using reflection. However, this would have seriously compromised the 
genericity and reusability of the SQL translation mechanism and hence, the 
aspectised persistence mechanism. Secondly, a well-engineered aspect 
requires one to evaluate the suitability of the available techniques for imple- 
menting the various concerns within the aspect. For instance, AspectI con- 
structs have been employed to identify points where persistence-related 
behaviour has to be composed while reflection has been used to keep the 
SQL translation generic and avoid duplication of transaction code during 
database access. However, the experience also shows that the choice of suit- 
able techniques is also constrained by the available set of tools and their 
interoperability. Ideally, the relationships in the bibliography application 
would have been implemented using the composition filters approach. 
However, given the available tools and their interoperability constraints. 
Aspect! introductions had to be employed for the purpose. 
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Based on this experience with the bibliography application, it can be 
argued that it is possible to aspectise persistence in a highly reusable fash- 
ion, which can be developed into a general aspect-based persistence frame- 
work. Nevertheless, application developers can only be partially oblivious 
to the persistent nature of the data. This is because persistence has to be 
accounted for as an architectural decision during the design of data-con- 
sumer components. Furthermore, designers of such components also need 
to consider the declarative nature of retrieval mechanisms supported by 
most database systems. Similarly, deletion requires explicit attention dur- 
ing application design as mostly applications trigger such an operation. 
However, this does not compromise the independent development or reus- 
ability of the aspect. While the need to expose retrieval and deletion func- 
tionality to the application had to be taken into account during the course 
of developing the persistence aspect, no specific implementation details of 
the application had to be accounted for. This resulted in a generic and 
highly reusable persistence framework. The framework does not rely on the 
existence of an additional layer masking the relational database features. It 
is very simple to adapt and reuse, i.e., concretise the DatabaseAccess 
aspect, specify the EstablishMapping aspect and use the Persistent- 
Data interface for retrieval purposes. However, for effective reuse such a 
framework (and aspects in general) should be complemented by a reuse 
specification. Such a reuse specification should clearly define the interface 
of an aspect’s behaviour, e.g., the exceptions the various advices might 
throw. This is essential as the integration phase in the development process 
needs to specify behaviour to respond to any exceptions raised by the 
advices hence, improving the soundness of the composition. 

It is also interesting to point out that the design of a persistence frame- 
work was not intentional. The natural separation of concerns was followed 
while developing the persistence infrastructure keeping the reusability and 
application independence requirements in mind and the framework natu- 
rally emerged. 




7. Conclusion and Outlook 



The term “Aspect- Oriented Database Systems” refers to the synergy 
between aspect- oriented software development techniques and database 
systems. This book has specifically focussed on the use of aspect-oriented 
programming techniques to improve the modularity of database systems 
and their applications. Several concrete systems and scenarios have been 
discussed to demonstrate the improved localisation of changes offered by 
the use of AOP and how this serves to improve various quality factors of 
databases systems such as customisability, extensibility, evolvability and 
maintainability. The use of AOP in this context is part of an upcoming 
trend to develop database systems that can be customised and evolved in 
line with “local” organisational and application requirements. (Dittrich 
and Geppert 2000), for instance, focus on the use of component-based 
approaches to improve the modularity of database systems. (Fisher, Good- 
all, et al. 2002), on the other hand, discuss the need for application-specific 
database systems and propose the use of domain-specific programming 
languages with embedded, domain-specific database systems for the pur- 
pose. AOP techniques offer the added advantage that they can be used in 
conjunction with existing mechanisms to improve modularity and custom- 
isability, e.g., componentisation and domain-specific development respec- 
tively. The explicit support for separation of crosscutting, systemic con- 
cerns offers additional support for separation of concerns. 

The book has also described the use of AOP to modularise persistence- 
related code in an application. Separation of persistence-related code, in a 
transparent fashion, is not a new phenomenon in database systems and has 
been the focus of extensive research in object data management (Cattell, 
Barry, et al. 2000; Roos 2002) and persistent programming languages (Mor- 
rison, Brown, et al. 1989; Atkinson, Daynes, et al. 1996; Atkinson, Daynes, 
et al. 1997; Atkinson and Jordan 1998). AOP can provide additional sup- 
port for such transparency through modularisation of persistence-related 
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concerns such as transactions, SQL translation and alternative or comple- 
mentary means for transparency of data storage and retrieval. 

It should also come as no surprise that database systems can serve as the 
basis for sharing aspects across applications and promoting aspect reuse. 
Database systems are no longer used for the sole purpose of record process- 
ing and support a variety of advanced applications including software asset 
management. It is, therefore, natural that persistence models remain in step 
with the development of new software development techniques such as 
aspect-orientation in order to support asset mining and reuse. 

The past few years have seen a significant shift towards advanced separa- 
tion of concerns techniques such as component-based and aspect-oriented 
development mechanisms. Aspect-oriented techniques have gone from 
strength to strength evolving from a programming-level mechanism to a 
development approach supporting separation of crosscutting concerns 
throughout the software life cycle. They have also been employed in con- 
junction with component-based approaches (Rashid 2001b). It would, 
therefore, be interesting to explore how aspect-oriented approaches can be 
used to provide further support for modularisation in database systems 
employing component-based designs. The benefits of using aspect-ori- 
ented requirements engineering (Grundy 1999; Rashid, Sawyer, et al. 2002; 
Sutton and Rouvellou 2002; Rashid, Moreira, et al. 2003), architectures 
(Tekinerdogan 2003) and design (Clarke and Walker 2001a; Clarke and 
Walker 2002; Katara and Katz 2003) approaches to support the develop- 
ment of database systems from the early stages are also worth exploring. 

In conclusion, this book has provided insight into the application of 
AOP techniques in an application domain central to most businesses today. 
The discussion demonstrates that important benefits can be derived from 
the use of AOP in terms of developing more flexible and evolvable database 
systems and applications. It also highlights that database systems should 
not ignore the needs of upcoming software development paradigms. The 
increasing interest in aspect-oriented techniques over the past few years 
and successful applications in the database domain reflect that they have a 
significant role to play in the development of software systems in years to 
come. 




Abbreviations 



The following abbreviations have been used in the book: 

• AODBs: aspect-oriented database systems 

• AOP: aspect-oriented programming 

• AOSD: aspect- oriented software development 

• API: application programming interface 

• BLObs: Binary Large Objects 

• CLObs: Character Large Objects 

• CORBA: Common Object Request Broker Architecture 

• CVDG: class version derivation graph 

• DAG: directed acyclic Graph 

• DBMS: database management system 

• JDBC: Java Database Connectivity 

• JDO: Java Data Objects 

• ODBC: Open Database Connectivity 

• ODBMS: object database management system 

• ODMG: Object Data Management Group 

• ODQL: Object Data Query Language 

• OO: object-oriented 

• OODB: object-oriented database 

• OQL: Object Query Language 

• ORDB: object-relational database 

• OVDG: object version derivation graph 

• RDB: relational database 

• SQL: Structured Query Language 
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